dinsdag 25 december 2012

Running the Apache Felix Webconsole from Eclipse

I have been told about the Apache Felix Web Console a couple of times. During all of these occasions the guy telling me this had this peculiar look in his eyes. The look that makes you think: "Okay dude, I can see that you are serious. I have to check this out." 



The first time I went down there I tried to follow the described steps. The page talks about an "all-in-one" install but it was nowhere to be found. Then I tried to install the individual components from the Felix download site but for some reason I went from one un-resolved dependency to another. So, at that point, they lost me.

Documentation... Once you are the expert you don't see where the newcomer gets lost. I am all to familiar with this. I believed we had created the easiest installation webpage for the Nebula community until I witnessed people trying to install.  

A few days ago I tried again, and basically with the same luck, so I started whining and left it again. However, it kept bugging me and I decided to finally research it until I was finished. And, you guessed it, it turned out the be quite easy.

Installing Apache Felix Webconsole into an Eclipse Installation

I am running a fresh copy of the Eclipse Classic installation. The first thing I did was to install the Felix webconsole. I downloaded the Web Console jar file from the Felix download site and dropped it into my Eclipse dropins directory.



Next I installed the three dependencies that are mentioned on the webconsole homepage:
  • Apache Commons IO
  • Apache Commons FileUpload
  • JSON
All of the above dependencies can be found in the Eclipse orbit repository. So I visited the Eclipse Orbit site and clicked on the download link to the right of the page. I always choose one of the latest stable builds and this is the link. That page contains the link to the P2 repository. 

Inside Eclipse, I fired up the "install new software" dialog and installed the three plugins. Please take care of the following:

Web Console needs an older version of commons io, version 1.4.0.  

Un-tick the "show only the latest.." checkbox in the dialog as indicated in the picture and select the three features from the list.



This should result in the following confirmation window:



Press Finish and restart.

Starting the Apache Felix Webconsole


The Web Console needs a web server to serve its pages. Fortunately, Eclipse Classic comes with a build-in web server called jetty.

After Eclipse has restarted, open the console view. From the console view, select to open the host OSGi console:


On the console prompt type "ss jetty"


I have number 93 so I type "start 93"


As you can see from the error, there is a socket error. Permission Denied. This is probably because jetty wants to start on a low port. And this is not allowed if you are not root. So, we need to tell jetty that it has to start on a high port.  Fortunately, this is documented on the webconsole homepage. Cool. It instructs you to pass the java system property:

-Dorg.osgi.service.http.port=8888

We can do this by adding this property to the eclipse.ini file and restarting.


Back in the Eclipse console we start jetty again and this time it is successful.  So, let's visit the webconsole and do a little dance:


Aiiii. It is not working! Why? We also need to start the webconsole bundle. 

"ss webconsole"



And now it works. Pretty cool!

Best Regards,

Wim


[1] http://felix.apache.org/site/apache-felix-web-console.html

zondag 7 oktober 2012

Why Eclipse e4? (the Egg Laying Woolmilkpig)


The Germans have a great expression for something that is supposed to do everything. They call it "Die Eierlegende Wollmilchsau" and it is a combination of a pig, a sheep, a cow and a chicken. It is the ultimate machine that replaces all others. How does this translate to Eclipse e4 RCP? 



We have started a cooperation with vogel/a GMBH and we have been trained by Lars in e4. The training lasts 5 days and it covers everything you need to know about creating an e4 application. E4 RCP consists of the new e4 specific technology combined with existing stuff like SWT and JFace.

The reason why I joined the course is to get up to speed with the latest RCP developments. Here is a document of my experiences and why I think e4 RCP is better than Eclipse 3 RCP.

My initial state of mind

I did not think e4 was really something that would shock me. After all, I am a seasoned RCP 3 developer and have trained many people in how to use the framework. Sure, the application model looked nice but I really did not consider it to be more than an improved manifest editor. 

I lost some interest during the development phase because I saw a number of things fall off the wagon, like XWT and OpenSocial integration.

What I did not realize is that I missed the point about core e4 technologies.  

Now that we know the gems of e4, we have decided to stop offering our courses based on the old Eclipse 3 RCP applications and completely switch over. E4 is the future for Rich Clients. and when we say Rich Clients, we don't just mean Desktop.

Let me try to explain why I think you should switch to e4. 

Reason 1, The 4th Generation of Frameworks

A 3rd generation framework, like Eclipse 3 RCP, can be viewed as a big scaffold that you use to build your application with. In contrast to scaffolds IRL, this scaffold never goes away and it will forever surround your application. 

If you use such a framework to create something, you typically extend or implement a class and implement the required methods. To give an example, to build an Eclipse View in Eclipse 3 RCP you need to extend ViewPart and because you need to do that, the scaffold needs to stay in place to support your application. 

Not only does this literally tie your application to the framework, another drawback of this mechanism is that code cannot be reused. I cannot use ViewPart outside the Eclipse RCP framework and if I wanted to re-use the user interface elements of a ViewPart inside the framework (for instance in a Wizard) then this is really hard and often requires serious refactoring.

In Eclipse e4 you do not extend or implement framework classes because you strictly work with POJO's. All hooks into the framework are based on annotations which are completely ignored if used outside of e4.

The supporting function of the e4 scaffold is much less then the old RCP. This means that an application based on e4 can be refactored to remove the framework. This is much harder in a third generation framework like Eclipse 3 RCP*.

do I hear impossible? Going once, going twice ... 

Reason 2, No API, No Cry.

(Girls, just swap "Man" and "Woman")
An extensive knowledge of the API is required in order to comfortably interact with the features of a framework. If you are a successful user of the Eclipse 3 RCP, then I congratulate you with your tremendous capacity to store abstract information in your brain. You must not only remember the various components that you use but also know where to get them. 

This has been inverted. You no longer ask for stuff through an API but you let e4 inject it.

Suppose you want to do something simple as calling back the UI thread to update the user interface. The only correct way* in Eclipse 3 is to ask the workbench object like in this code snippet:

Display display = PlatformUI.getWorkbench().getDisplay();
display.asyncExec(runner);

This has been replaced by the following code:

@Inject Display display;
display.asyncExec(runner);

No more tedious searches to get the framework objects. You just let e4 inject everything directly into your POJO. "But I already know the API", you might say. But what about your new co-workers? (see reason 7) 


Reason 3, The Dynamic Application Model.

E4 uses a dynamic in-memory model of the running application. The dynamic nature of the application enables you to create, change and destroy model elements at run-time.

For example, it is very difficult to hide views from users in old RCP applications. One often needs guarding code inside the view to prevent the user from accessing it's content. There is no real concept of hiding views, especially if you also deploy your applications as plug-ins. In e4, you can iterate through your model, and based on the security level of the user you can perform actions (like deleting protected views from the model altogether)

Model elements like views and commands can be tagged. Tagging enables you to add domain specific information to the e4 application model. These tags can be read at run-time and based on their values you can apply application logic.

As an other example, you can generate a user interface completely from an empty model. Suppose you have a tool that generates an application. Instead of generating code in a static way, you could interpret information from a database and generate a user interface on the fly.

Reason 4, Dependency Injection FTW.

The e4 components are managed by the Dependency Injection Manager. The general concept of the Eclipse D.I. Manager is fairly simple; the various components of the e4 framework maintain a parented hashmap that contains all object instances that the D.I. framework can inject. This parented hashmap is called the D.I. Context.

I promise it will not hurt.
For example, the Eclipse bootstrap code is responsible for creating an instance of the Display class. This instance is then placed into the D.I. context. If any of your model objects (views, windows, menu's, handlers) require the correct instance of the Display class, it is simply injected by D.I.

Now what makes D.I. really super-super-cool and powerful is its capability to also create and maintain your own components. Consider the following class:


If you ask the D.I. framework an instance of this SomePoorClass then it will first check the D.I. Context if the object already exists. If it does not, it will create it courtesy of the @Createable annotation. Not only will it be created but also the dependencies annotated with @Inject will supplied. As an additional bonus, if any of the injected objects change in the D.I. Context, they will automatically be updated in the SomePoorClass instance. If I would tell you this during the training, you would have noticed that my voice has shifted one octave to the higher pitch. Pure enthusiasm. Super-super cool!

Reason 5, Communication

Eclipse e4 is using a global event notification system. It is based on the Equinox implementation of the OSGi Event Admin Service specification.
A special simplified class is placed on top of this implementation and is called the IEventBroker. The implementation dictates that an event can be send with send(..) or post(..). The passed parameters are the topic string, which is a "/" delimited string and an associated object called the payload.  The difference between send and post is that the former is synchronous and the latter is not. 

In addition, you can use the broker to add a listener that will be called when a topic of interest arrives. 

However, with the e4 D.I. framework in control there is really no need to register such a listener.

You can ask e4 to inject events directly into an interested method. Setting up an event listener becomes a trivial task.  



In this way you can handle your own events or tap into the events send by the framework. We all use the same global event bus.

Reason 6, GUI Independent Rendering Engines

As you know, Eclipse and SWT are married. It appeared to be a solid marriage but after Eclipse has discovered the temptations of the internet she is not so sure she want to be so monogamous as she used to be. 

The Platform developers have equipped Eclipse with a GUI independent rendering framework. 

As a result of this, there are several experiments with alternative rendering engines. Please check Kai Toedters work on Github, the e4 SWT to Web work by the RAP team, the blog describing the RAP rendering experiments of Ralf and Lars and there is a rendering engine on github for Vaadin by Rushan R. Gilmullin

A special mention goes to the JavaFX rendering engine by Tom Schindl. Tom has spent a lot of effort in this engine and creating JavaFX integration for Eclipse

This promises to take the framework you already know and love to render outside of the desktop. How cool is this?

Reason 7, Steep Learning Curve / Shameless Pitch

First let me tell you my own experience. 6 weeks ago, I had next to nothing e4 experience. Going through the vogel/a course, it took me 2 days to understand what was going on. Like I already said, I am an experienced Eclipse 3 RCP developer. It took me another week or so of fairly intense study to make me confident enough to teach e4 to others. For this study I used the e4 book Lars has written, the content available in the e4 wiki, the source code and the vast experience I already acquired through the years. 

For me, the learning curve was very steep. Meaning that I could acquire a lot of information in very little time. Since then I have seen what the training did to other experienced RCP developers and it was basically the same. After two days the e4 concepts were clear. The other days were used to learn additional framework capabilities based on the concepts.

To me and the other experienced RCP developers there was no doubt about the power and simplicity of the new framework. The concepts are totally cool.

Another experienced programmer which had never done anything with Eclipse or SWT but had developed a large Swing application, was completely convinced of the powers of Eclipse e4 and OSGi. He had fully understood the concepts and was able to create an e4 application from scratch within a couple of minutes. 

Can you do it without training. Sure. Go to Vogel/a's website and look at the wealth of information available. If that is not enough, go to the forum and ask questions. If that takes to long, buy the book. However, there is nothing like a good old crash course to erect the learning curve.

Be aware that my company has adopted the same course materials and approach. So this last reason can be seen as a shameless pitch. However, there is the topic of my reputation.


Questions and Answer

Q. Must I Switch to e4 RCP? 
A. Yes. If your code is based on Eclipse technology you must move on. 

Q. Do you need to switch today.
A. No, but do not dwell in old RCP. Be decisive and start planning the conversion process. Plan new projects to be developed in e4.

Q. Is the training really needed?
A. Only if you don't want to waste time.


Q. Is e4 stable enough to host my mission critical application today.
A. Today? No promises but it is getting there.

Q. What do you mean? Does it contain bugs!?!
A. That is a promise.

Q. Are there more questions?
A. And answers too. Check this.

Is it the Egg Laying Woolmilkpig?

Frankly, there is no framework that can match Eclipse RCP. The problem for me with other frameworks has always been the 80/20 rule. 80% possibilities and 20% struggle. Eclipse is programmed in and with Java. Anything is possible. 

But you tell me. I love your comments.


...

zaterdag 2 juni 2012

Eclipse base location uri for menus

Since they are impossible to find on the net here is the list of all base location uri's in eclipse that are used in the org.eclipse.ui.menus extension point:


menu:org.eclipse.ui.main.menu // the top-level menu
popup:org.eclipse.ui.popup.any // all pop-up menus
toolbar:org.eclipse.ui.main.toolbar // the top-level tool bar
toolbar:org.eclipse.ui.trim.command1 // the top left trim (main toolbar area)
toolbar:org.eclipse.ui.trim.command2 // the top right trim (perspective switcher area)
toolbar:org.eclipse.ui.trim.vertical1 // the left vertical trim
toolbar:org.eclipse.ui.trim.vertical2 // the right vertical trim
toolbar:org.eclipse.ui.trim.status // the status line trim

to access the menu/toolbar/popup of a part (view or editor):

menu:partid //the part's chevron menu

toolbar:partid //the part's toolbar (cannot contain other toolbars)
popup:partid //the part's popup menu (register the context menu in createPartControl first)



zondag 18 maart 2012

Design a Nebula Logo and win $100

The Short Story

The Nebula project needs a new Logo. File a new logo design using this bug and you could win $100.
Showcase your logo here: http://wiki.eclipse.org/Nebula/Artwork

The Long Story

The Eclipse Nebula project is slowly moving out of incubation. Artifacts of this process are going to be stable releases, continuous builds and easy to get documentation.

A new design of the Nebula website will be part of this although I fear that it will be quite hard to get resources for this job.

When looking at the great design of the Xtext website, I must admit that I am a little jealous. Because nothing drives production better than competition, I thought it was time for a new Logo for the Nebula project.

A great designer is somewhere inside me, waiting to blossom, but, to be completely honest, when I show my creations to people, I often get advice to hire some professional help. Nevertheless, I was thinking that an Ambigram would make a nice Nebula Logo. When designed properly, Ambigrams are clear on their own but can be read upside-down as well. So after fiddling around with it a little bit, this was the result.
As you can read from the mail thread, it did not land well with the other readers of nebula-dev. Edwin Park replied with a promising design:


We decided to open a bug and make a real contest out of it. So far we have the following proposals. If you can do better, help us out and you could win $100. The logo will be chosen by the readers of the Nebula-Dev mailing list (you can subscribe here).



   

 
  


  
 

 

zaterdag 18 februari 2012

News from Eclipse Nebula

Every time I teach one of my RCP classes I take some time to discuss the Nebula project. An RCP application is not complete without at least one of these beautiful widgets. In our own applications we make extensive use of the Nebula project.

About a year and a half ago I managed to get one of my own widgets in the project as well and so i became a Nebula committer. Yay!

Tom, Nicolas and others did a lot of work restructuring the project at that time but it got stalled. IIRC this was mainly due to problems getting the Eclipse infrastructure working for us and Tom being buried in e4.

However, this left us with an unfinished build,  no official download site and as a result some of the widgets were self-hosted. In the mean time new widgets were offered to the project that did not get enough attention. A few weeks later, Tom send a message to the list. After pondering it for a while, I decided to volunteer for the position as project lead on a temporary basis (read: you will never get rid of me).


Restructure
Since then we managed to get the project going again. My first action as wannabe project lead was to move forward with Mickael Istria's Treemapper that was waiting to be accepted. I filed a CQ to the EMO to get the Treemapper through the IP process.

I could not know at the time that this was a smart move because Mickael proved to be a build magician and together with Nicolas we managed to complete our (Tycho) build, with test, signing and upload to the Eclipse download server. There are now only a few seconds between a check-in and the availability of the code on the Eclipse download servers.


Housekeeping
The next steps in the restructuring was the move to git, restructure and refactor of the widgets (we are no longer in the swt namespace), the completion of the restructure documentation and finally the proposal of the new project structure.


New Widgets
In the mean time, new widgets are included into the Nebula project. So please allow me to introduce:

TreeMapper
Mickael's TreeMapper widget can be used to link entries in two trees by using drag and drop. It can be used for mapping fields to tables, users to capabilities, eggs to sausages, and so on. Read all about it.


Picture Control
A widget made by Angelo Zerr and Pascal Leclerq. It is a widget for easy picture control. It enables upload and display of a picture and, it also runs in RAP. Read all about the Picture Control.

Pagination Control
Another brand new widget by Angelo and Pascal is the Pagination Control. There are some good use cases when you have to work with large data sets. We know the pagination paradigm from the web but why should that not be available on the desktop. So here is a good alternative to lazy content providers and virtual trees and tables. Did I already mention that it also runs in RAP? Read all about the Pagination Control.


NatTable
Now it is time to wait for the legal stuff to happen in the NatTable proposal. NatTable is currently self-hosted so go over there and take a look. We have been using NatTable in our own product and we are very happy with it's versatility and speed. All the better that this is coming to Eclipse Nebula. Edwin Park will be the lead of the sub-project and we are looking forward to find a good place for NatTable in Nebula.


Example View
Checkout the widgets by downloading them from our update site. Make sure to also include the example view and the examples of these widgets. 

Cheers,

Wim