Skip to content

Archive

Tag: osgi

The Eclipse RCP became a prominent platform for building client software. One of the delivery mechanisms supported by Eclipse RCP is Sun’s Java Web Start (JWS). Since Galileo Edition some changes has been introduced in the platform. This article provides some hints for creation of the RCP delivered by Java Web Start.

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.

OSGi HHOSGi HHOSGi HH

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.

hotel eastThe organizers of the upcoming OSGI event selected a promiment Hamburg’s nightlife location. The location is a evidence of modern design. The entire hotel is equipped with non-standard items in various forms and colors and commemorates on Dali and Gaudi in the same time.

Topic: Why Modularity is Important

When: September 9th, 2008, 19:00 CET, Registration required

Where: East Hotel Hamburg, Simon-von-Utrecht-Strasse 31, 20359 Hamburg / Germany

Abstract: Many developers are finding out that modularity has a significant influence on the development process. But unfortunately, Java has no concept of modularity, all JARs are placed on a linear classpath. Many projects have developed in-house plugin frameworks to achieve some modularity. The OSGi Service Platform is a standards based framework used by many projects. Some of the best known projects that use OSGi are Spring and Eclipse. There are many open source projects and commercial companies that have implemented the specifications: Apache Felix, Knopflerfish, Eclipse Foundation, ProSyst, IBM, Siemens, Hitachi, Samsung, etc. This presentation will analyze the problems with (the lack of) Java modularity and explain how OSGi provides many benefits for the development process as well as make the applications itself easier to maintain and extend.

Author: Peter Kriens