Have you ever had trouble with your customers downloading the wrong version of your eclipse product to their box? We had always trouble with 64bit windows with 32bit Java installed, no one can expect from customers to know what java version they have installed.
So today I started off with a slighty customized version of the standard eclipse p2 installer. I got the 3.6.1 maintenance branch from the cvs repo, as current head doesn't compile against the 3.6 platform. I removed the shared install options, as they only would confuse users.
The idea was to webstart the installer to give users an as easy as possible download experience. But the built-in mechanisms of eclipse give us some tedious manual work to do to build such a thing.
First I created a feature containing all the plugins necessary to run the p2 installer, and added all the other platform plugins that are needed to support mac and both windows platforms. (We do not support linux by know, but that should be straightforward). One has to set the platform properties of the platform dependend plugins in the feature manifest manually, a task I always forget until I try to run the build.
Then change the p2 installer product configuration to be based on features and add you newly created feature. Create a keystore if you do not already have one and follow the instructions from the eclipse help to create a webstartable application.
Unfortunately the webstart export does not support multiple platform export, however if you have included the platform dependent plugins, you will find them in your feature.jnlp file, but with all version attributes set to 0.0.0
Now do a second export of the feature, uncheck the JNLP creation option and export for multiple platforms. Leave the signing option on as we need signed jar files for webstart. Copy all the exported, platform dependend plugins from the export to you webstartable plugins folder. (You could get them from the delta pack as well, but then they wouldn't be signed with your key). Now the tedious work: replace the jar file path with version 0.0.0 in your feature jnlp wit the correct paths to your added plugins. The platform and architecture selection in the jnlp will already be there.
To make the p2 installer work via webstart we need to do a third export. This time export the product for you main platform only and get the configuration directory from the export, copy it to the root folder of your webstartable export (simpleconfigurator needs a config file from there thats not included in the jnlp export).
Set up your main jnlp file as suggested in eclipse help and add some properties for the p2 installer:
<property name="org.eclipse.equinox.simpleconfigurator.configUrl" value="http://yourwebstarthostpath/configuration/org.eclipse.equinox.simpleconfigurator/bundles.info"/>
<property name="org.eclipse.equinox.p2.installDescription" value="http://yourwebstarthostpath/installer.properties"/>
Don't forget to add your customized installer.properties file. Now upload this to your webserver and voila, we have a platform independent installation experience for our product.
Don't mind to ask if you run into any troubles. Getting the jnlp files work properly is sometimes confusing.
Saturday, January 29, 2011
Sunday, January 2, 2011
I spent some time experimenting with technology, including virgo and e4 as a platform for my project over the last couple of months. Building a new release yesterday I had to step back on Eclipse 3.6 because of some small but annoying issues with the compatibility layer on e4. There where still some problems with the workbench selection and the visibility to toolbar/menu contributions. However I have to say that the e4 team was "mostly always" glad seeing me open some new bugs I found, but all in all I decided not to deliver on the new platform and give it some more time to become mature. But at least I included the e4 styling engine to give me some control over fonts. I use lots of UI Forms and I found it not easy to get a good color styling, but I guess I've read thats out of scope for the styling eninge, bad for me. Still have to open another bug for the splash handlers that don't seem to work on e4, but I guess that will not be the most important one to fix :)
Today I finished my migration of a (small) demo app to the new Vaadin 8 API. First of all: Vaadin 8 has a compatibility layer. Everything ...
In this tutorial we will put together a full application stack for a multi-tenant architecture. We will be using Vaadin and Vaadin-Sprin...
Vaadin 8 (currently in beta) comes with a whole new DataBinding API that makes heavy use of the Java 8 Lambda Features. Unfortunately Java...