Packaging

In order to package the RCP I suggest to use feature-based products as described in a previous article. Following it, you should have a top-level plug-in (also refered as product-defining plug-in) and top-level feature, which is called “wrap”-feature in the context of the Java Web Start.

Exporting the product

Before you start with Java Web Start (JWS), export the product and make sure it starts as a standalone application. In doing so, you have to ensure that your references to the plug-ins are correct. One of the way of doing it is to hit the Validate button in the top left of the product editor. If the validation is successful, try to export the product. The PDE builder will run and create a distribution. The errors of the compiler/builder/assembler, if any, are reported to files zipped to the logs.zip file in the distribution directory. A prominent error is

Compliance level '1.3' is incompatible with source level '1.6'. A compliance level '1.6' or better is required.

Which actually means that the plug-in classes has not been compiled at all. In order to avoid this error make sure to set the following properties in the build.properties file of the corresponding plug-in:

javacSource=1.3
javacTarget=1.3

Exporting the wrap-feature

After a successful export of the product, just export the top-level feature (the wrap-feature). Make sure to provide the signing information, since JWS requires all resources to be signed. If you are aiming to deliver for different platforms, make sure to define a target platform (Window > Preferences > Plug-in Development > Target Platform) which contains a Delta Pack. A Delta Pack is a set of plug-ins which can be downloaded separately on the Eclipse Homepage. Also, don’t forget to switch over to the Java Web Start tab of the Feature Export Wizard, activate the checkbox “Create JNLP manifest for the JAR archives” and specify the site URL where the resulting JNLP will be located. Make sure all your features has the provider attribute set, since it is used as the “vendor” inside of the JNLP file, which is a mandatory attribute.

Creating the main JNLP

The PDE build will run and create a distribution in the specified directory. Along with the exported JARs in features and plug-ins, the packaging script will generate the JNLP descriptors for every feature. Still, the main JNLP file required for launching the application is missing and has to be provided separately. Here is, how it looks like:

<?xml version="1.0" encoding="UTF-8"?>
<jnlp spec="1.0+" codebase="http://localhost/app/" href="app.jnlp">
    <information>
        <title>application titel</title>
        <vendor>provider</vendor>
        <offline-allowed/>
    </information>

    <security>
        <all-permissions/>
    </security>

    <application-desc main-class="org.eclipse.equinox.launcher.WebStartMain">
	<argument>-product</argument>
	<argument>de.techjava.app.webstart.productid</argument>
	<argument>-application</argument>
	<argument>de.techjava.app.webstart.appid</argument>
    </application-desc>

    <resources>
        <j2se version="1.4+" ax-heap-size="128m" />
	<jar href="plugins/org.eclipse.equinox.launcher_1.0.201.R35x_v20090715.jar"/>
	<extension name="wrap feature" href="features/wrap_feature_1.0.0.jnlp" />
	<!-- OSGI setup -->
        <property name="osgi.instance.area" value="@user.home/app"/>
        <property name="osgi.configuration.area" value="@user.home/app"/>
    </resources>
</jnlp>

Important is to specify both, the product id and the applciation id, otherwise you will see the “Application id not found” exception. Of course you can specify additional options as command-line arguments of the launcher itself. I found it useful to be able to let the OSGi running and then connect to it and query for loaded bundles. You can do it by adding the following arguments:

	<argument>-console</argument>
	<argument>1234</argument>
	<argument>-noExit</argument>

This will allow to connect via telnet with running OSGi, even after the application finishes.
This is basically it.

Yesterday, the OSGi session took place in Hotel East in Hamburg. Peter Kriens, the OSGi evangelist showed a wonderful Zen Presentation on OSGi. I wrote a lot during his talk which happens to me very seldom. Here are the core statements I understood:

• The core difference between usual plugin architectures and OSGi is that OSGi concentrates on collaboration of the components.
• OSGi delivers a controlled environment, in which the question if a component runs or not can be answered in beforehand.
• OSGi bundles use metadata (about versions, dependencies, etc) to predict an error, not discover it in runtime.
• OSGi has a very narrow API containing the minimal common part.
• OSGi consists of module, life cycle and services layers. The initially developed services layer required smart class loading mechanisms (module layer).

1. The module layer is desigend to control the class loading machanisms (e.G. structureal class loader hierarchies instead of a linear classpath)
2. Life cycle layer adds a management API (e.G. inform the others about installation event)
3. Separation of concerns is promoted by definition of services for different tasks.

• Services are used for decoupling of system parts (This is a standard application of service-orientation).
• OSGI makes dependencies explicit (private, import, export)
• OSGI tries to make the system managable, taking dynamics and lifecycle as fisrst-class citizens
• OSGI will be extended to support distribution: the team works on policies, SLAs, etc…

I liked the talk and the way how Peter Kriens addressed the problems of OO. I was confirmed in some ideas about coupling that will be layed out in my thesis. After the presentation we had a delicious meal and wraped up the evening with interesting discussion about pros and contras of OSGi. Peter Friese showed me some remote OSGi staff, he was playing with. The lack of documentation in this area makes it a little difficult, but I hope he will post some news on it. As usual, you can find other pictures in my FlickR gallery.