Sunday, June 29, 2008

Eclipse Ganymede - P2 Shared Installations (Bundle Pool)

Eclipse Ganymede and P2 will change your update workflows from ground up.

There are some Cons (I'm missing the external locations from Software Update),

but many Pros so for me its time to change.

If you don't want you can still use the old Update Manager. (Preferences - General - Capabilities)

There are many new things in P2 - today I'll concentrate on:

  • Dropins - a folder where you can place and structure plugins. These plugins were scanned at startup automagically by Eclipse P2.
  • Bundle Pooling - now its possible that some Eclipse Installations can share their bundles using the Bundle Pool.
In my project I'm using some Eclipse Instances:

  • Eclipse for Modeling (EMF, UML2, openArchitectureWare, ...)
  • Eclipse for OSGI Client/Server (Eclipse Riena, RCP, Equinox, EasyBeans, ...)
  • ....

The old classic way I had to download the Ganymede Packages for Modeling and also the Ganymede Packages for RCP/Plugin and then manage them separately.

Eclipse P2 allows bundle pooling and now we'll try to install this.

Attention: All installation examples in this blog are OSX specific - perhaps you have to make some fine tuning for your OS.

Shared Installations - first try

As good Eclipse „citizens“ at first we look at the Eclipse wiki and read from Equinox P2 Getting Started and Equinox P2 Installer and then we're ready to start:

Download the P2 Installers from here - we choose the Mac OSX version:

Doubleclick to unzip the Installer into /your_path/e34p2installer and open the installer /your_path/e34p2installer/eclipse/

We're choosing Shared install, select our Product install directory (/your_path/e34modeling) and start the p2 Installer.

It takes some time to download the SDK bundles - unfortunately I cannot select a prefered mirror and there's also no chance to select the Friends of Eclipse Mirror ;-)
see @ Bugzilla 215916

Suddenly the window of the P2 Installer disappears without any message - but lets think positive and start the new Eclipse from /your_path/e34modeling.

All runs well without any problem or error :-)

But its not the end of the story - otherwise there would be no reason to write this blog ;-)

Where are the shared plugins stored ? Where's my bundle pool ? You remember: there was no possibility to select the bundle pool location from p2 Installer.

Searching the Getting started under Bundle pooling we found an example:

Documents and Settings
<-- shared bundle pool But there are no plugins - the plugins of the bundle pool were stored into the P2 Installer location: /your_path/e34p2installer/eclipse/p2/ org.eclipse.equinox.p2.touchpoint.eclipse/plugins/

Now you're in luck if you don't followed the advice to delete the P2 Installer („... When finished, you can delete the installer...“) ;.-)

We need a way to select the location of your bundle pool - lets start a next try:

Shared Installations - second try

Download and unzip the P2 Installer as described above and look into the p2installer.ini file (you'll find this file under /your_plugin/e34p2installer/eclipse/ p2installer.ini ).

Inside the p2installer.ini you'll find a link to a properties file. Please open in your webbrowser and you'll see:

eclipse.p2.profileName=Eclipse SDK

Copy the content from the browser window into an empty textfile and add following entry pointing to the bundle pool:

Save this textfile under /your_path/e34p2installer/

Now we have to open the p2.installer.ini file to change the path of the

/e34p2installer/sdk-installer.propertiesfile: /your_path/e34p2installer/

Start the P2 Installer, select the product install directory (/your_path/e34modeling - screenshot see above from first try)

The same happens again: the P2 Installer appliation disappears without any message - but Eclipse (from /your_path/e34modeling) runs without problems and now all shared plugins are stored in our bundle pool under /your_path/e34pool/plugins :-)
2008-07_02 add-on: its not ok, that the P2 installer disappears - you have to add more memory, delete all and start again. see additional info in blog P2 Installer Trouble

Now we want to install the second Eclipse installation (/your_path/e34osgi_rcp) and so we start again the P2 Installer, select our product install directory, choose Shared Installation and really - this time it takes only some seconds to "download" and install the Eclipse SDK :-)

Really great P2 !

But whats that:
This time the P2 Installer window remains open and asks if we want to start Eclipse SDK immediately.

After some tests it was reproducable: in shared installations the first time a bundle pool was used the p2 installer disappears without any message.

Both SDK installations run without any problems - About Eclipse - configuration details logs that all bundles come from our bundle pool.

Good work, P2 :-)

Configure Eclipse Installations

The first steps were easy - but now you have to do some work: - unfortunately there are no prepared shared Installs like Ganymede Packages (I have found none)

Instead of selecting a whole package or groups of plugins we have to choose and select them plugin for plugin: Please start your two SDK installations and select menu Help - Software Updates...

Installed Software shows the already installed Eclipse SDK.

Got to tab Available Software - Ganymede Update: there you'll find the needed plugins. P2 makes sure, that all dependencies will satisfied, only correct combinations will be installed - so we always have a correct installation running.

In my ERP project one Eclipse installation (/your_path/e34modeling) contains the plugins from Ganymede Modeling Package + ECF and the other Eclipse installation (/your_path/e34osgi_rcp ) contains the plugins from Ganymede RCP/Plugin Package + Ganymede Reporting + Subversion.

To get an idea whats needed you can take a look at the feature lists of the Ganymede Packages, per ex. for the modeling package:

After configuring both Eclipse Installations we can look at our bundle pool to see that all plugins are contained in the one and only bundle pool :-)

Would be really nice using Software Update to select bundles directly from your bundle pool. This would be an easy way to get bundles not contained in the actual Eclipse Installation, but already installed in another Eclipse application sharing the bundle pool.
So you have to select all bundles thru the updatesite - even if they are already contained in the bundle pool.

Dropins and Bundle Pool

After finishing the installations using Software Update... in many cases you have to install more (external) plugins (bundles).

You can use two different strategies:

  • Bundles from Update Sites (Menu Software Updates... - Available Software... Add Site...) - this works the same as in previous Eclipse versions, but without the possibility to store them at external locations
  • Bundles using the new Dropins folder (a „Watched Directory“). At startup Eclipse will scan this dropins folder automatically to see if there are new or changed plugins. All bundles from the dropins folder are added to the current Eclipse Installation.

This dropins folder will be found directly inside your Eclipse Installation directory parallel to the Eclipse Application.

You can also use an own extra dropins folder: simply add a parameter into eclipse.ini (/your_path/ /your_path/e34shared_dropin

This extra dropins location can be used from more then one Eclipse installations - so you can use it as a shared dropins (watched directory).

Now we have all pieces together:

Each Eclipse Installation only uses those bundles from bundle pool, which were selected from Software Update..., also the bundles from the (default) own dropins folder and perhaps bundles scanned from an extra (shared) dropins location.

You can put bundles into a dropins folder in different ways as decribed into the Getting Started.

Using link files inside your dropins directory you can manage external locations, but you loose the possibility to install them from inside Eclipse using Software Update...

Shared Installations and Target Platforms

I found out some problems with shared installations and the use of target platforms (Preferences - PDE - Target Platform).

If you create a target platform only from external locations then there's no difference to previous versions of Eclipse because you select the bundles to use by yourself without using bundles from your current Eclipse application.

But if you dont want to configure the target platform completely and instead use your current Eclipse as target, then there are some bugs:

  • Using Eclipse as shared installation you cannot select the bundles configured for your current Eclipse application as target platform
  • Bundles from dropins locations are not recognized in shared installations

Using Shared Installations the default target platform points to the bundle pool listing ALL bundles from your bundle pool, so you see also bundles from other Eclipse installations in you default target and you have to deselect the not-used bundles:

I think there should be also an option to automatically „Disable bundles not used in current Eclipse Installation“.

Next problem with dropins in shared installations. Getting Started... notes „In other words, new plug-ins installed via the dropins folder behave exactly like plug-ins installed via the user interface.

Attention: If you're using a shared installation the bundles from your dropins are missing !
You only see all bundles from pool (and there you are seeing too much as described above) and you dont see the bundles from your dropins.

The only way to change this is using Add.. for all plugins folders inside your dropins. If you have structured your dropins, this means you have to select each plugins folder from there. It can happen easily to forget something or loosing the overview.

Shared Installations brings you much more comfort, but also more work with target platforms :-(

If you're using separate (not shared) installations then the behaviour is as aspected - the bundles from all your dropins plugins folders appear automagically in your target platform:

I hope, that these bugs will be fixed soon:

Bugzilla 236923 [installer] p2 shared installation does not works without the installer directory
Bugzilla 238947 P2 Installer Window disappears
Bugzilla 238949 P2 Shared Installations - Target Platform too much bundles
Bugzilla 238950 P2 Shared Installations - Target Platform Dropins missing

and some enhancements as well:

Bugzilla 238952 Feature Request P2 Software Update should be able to select from Bundle Pool
Bugzilla 238953 request P2 Installer select Bundle Pool Location

as always: if you're interested, then please Vote for the Bugzillas ;-)


Over all P2 is a great step into te right direction - and please remember: its the first release - so give it a try !

the blog in german

Monday, June 16, 2008

Eclipse Ganymede - IDE and platform

2008 - june - 25
I started using Eclipse with version 2 as Java IDE.

Now (25th of june 2008) version 3.4 (Ganymede) will be ready to download.

Eclipse evolves over the years and now acts as a platform.

There are so many projects hosted at - who knows all their names...

The Ganymede release counts 24 projects ready to download.

In my ERP project I'm using

  • Eclipse as IDE
  • Eclipse RCP - Rich Clients under windows and OSX
  • BIRT - Reporting
  • Eclipse Riena - Remote (Client/Server)
  • Equinox - OSGI Plattform
  • Eclipse Modeling - openArchitectureWare
  • SWT / JFace / Eclipse Databinding - GUI
  • Mylyn - Taskmanagement
  • .....

Remark: Eclipse Riena is a new project and not part of Ganymede

Here are some of the news worth switching to Ganymede.

It's only a small part of all the new things making your daily work easier then before - wether you're using Eclipse as IDE, for Plugin - Development, with Mylyn, Birt or other projects ...

More comfort developing plugins (PDE)

Plugin Spy

tells you all you want to know from dialogs or windows.

on my Mac under OSX I couldn't use the keystroke
alt-Shift-F1 - after changing to alt-Shift-F13 it works.

Launch Configurations now can be exported to the local filesystem and also imported from there.


I'm using variables in my launch configurations - so they are portable and I can easy change them between different projects exporting / importing to local files.

PDE Tools --> Convert Jars to Plugin-Projects...

In PDE now its possible to create a plugin - project from a single jar. This makes it easy to design a clear plugin structure without storing external jars inside of your bundles.

Attention: You should only create your own bundle if there doesn't exist one for this jar. Please search at first at OSGI or at SpringSource Enterprise Bundle Repository.

Java Editor

Breadcrumbs: the Java editor optionally shows a breadcrumb bar.

From this bar you can easy navigate through the path of your java file and tree structures to open other java files in the editor - a very fast and comfortable way to access other classes, interfaces, methods,... from your current context.

JavaDoc Hover
You know the situation: pointing with your mouse cursor over a declaration a hover shows you JavaDoc informations.

Wouldn't it be great to jump directly into the hover, scroll the text etc. ?

With Ganymede you can do it now !
Point your mouse a second inside the hover and you can jump in and scroll or even execute some actions from there. (Please watch the toolbar at the bottom)

For me this is one of the coolest things in Ganymede.

Better support for OSX

JREs: All installed JRE‘s will now be detected automagically.

Voice Over (Command-F5) is now supported from Eclipse. Maybe I'll need this later.

Drag‘n‘Drop support in trees now shows the insertionpoint more exactly then before under OSX.

Mac Cocoa Port of SWT is still under construction and not ready to use with Ganymede :-(
But there must be a reason to wait for first milestones of Eclipse 3.5 ;-)

this bog in german

Catch-22 Logging with OSGI Frameworks

Logging is easy and there are no problems since apache.log4j and apache.commons.logging etc. exist. Using OSGI bundles its also easy to have the correct versions of bundles in your classpath. Standard Bundles can be re-used easy in OSGI frameworks - the newest example in this direction is SpringSource Enterprise Bundle Repository. Hey - logging paradise is out there ....

My actual project (ERP solution) has to integrate Eclipse Riena, EasyBeans and Equinox. Some problems were to resolve to make Riena and EasyBeans run under Eclipse + Equinox 3.4.RC4. (see also here and here)

The focus of this blog is only logging if these projects were used together - I'll talk later about the functional use.

The first small problem was easy to solve: Eclipse Riena needs a special version of equinox.log - replacing the equinox.log bundle from Equinox SDK with the version from Riena also works with EasyBeans.

Riena Logging

Riena has a dependency to log4j (Require-Bundle) - would be better to use Import-Package instead to make it possible to use log4j Bundles from other repositories.

Riena uses Jetty (contained in Equinox SDK and Platform SDK), Jetty itself has a dependency to org.apache.commons.logging (Import-Package).

All works well with Eclipse Riena - org.apache.commons.logging detects org.apache.log4J and uses this implementation.

EasyBeans Logging

EasyBeans components are also dependent from von commons.logging (Import-Package) and they found this package as part of the EasyBeans Bundle ow2-bundles-externals-commons-logging.

As expected - this works wel with EasyBeans - commons.logging sees no log4j and uses the Java JDK Logging.

Riena and EasyBeans Logging - the problems

Are we happy with logging ? YES ! ...if we only use Riena OR EasyBeans - but not together :-(

Unfortunately the logging in EasyBeans has an implementation only working with JDK - Logging.

But org.apache.commons.logging chooses log4j - if found - and doesn't look for the JDK logging as implementation.

Running Riena and EasyBeans without changes together (changing start-level doesn't matter), then there's an error from commons.logging @ EasyBeans Bundle: NoClassDefFoundError: org/apache/log4j/Category

Next try: We remove the Equinox Bundle org.apache.commons.logging. EasyBeans Bundle ow2-bundles-externals-commons-logging also exports the contained org.apache.commons.logging - packages.

Starting again bundle org.mortbay.jetty reports an error: org.apache.commons.logging expected from version 1.0.0 - the EasyBeans Bundle instead exports org.apache.commons.logging without any version.

Another try: We replace org.apache.commons.logging with from SpringSource Enterprise Bundle Repository and restart. Now reports an error: import of log4J needs version 1.2.15, org.apache.log4J from Riena is version 1.2.8 and doesn't match. We can't use from Spring, because Riena uses Bundle-Required instead of Import-Package.

Also EasyBeans reports an error: No suitable Log implementation

EasyBeans cannot use log4j as logger - only JDK logging.

Riena and EasyBeans Logging - the solution

  1. use equinox.log_1.1.0.HEAD from Riena instead of equinox.log_1.1.0 from Equinox SDK
  2. remove org.apache.commons.logging from Equinox SDK
  3. patch org.mortbay.jetty from Equinox SDK / Platfprm SDK: remove version from Package-Import org.apache.commons.logging

It's not an elegant solution, but it works: I'm able to log from Riena and EasyBeans running together in Equinox !

My wishes

  1. Riena should use Package-Import instead of Bundle-Required for org.apache.log4j (Bugzilla 237221 and Newsgroup)
  2. Riena should use standard equinox.log_version instead of equinox.log_version.HEAD, perhaps adding a fragment for additional functionality from equinox.log. (Newsgroup)
  3. EasyBeans should also work using „standard“ org.apache.commons.logging bundles (from Equinox, Spring etc). EasyBeans should also allow log4j as logging implementation (JIRA)
This would make life as an OSGI - application developer easier. Please vote for the bugs - thanks !

blog in german

Thursday, June 12, 2008

Eclipse Riena Getting Started in Ganymede (Eclipse 3.4)

Only two weeks remaining and the next Eclipse Version 3.4 (Ganymede) can be downloaded. This time there are 24 projects together with simultan releases.

It makes sense to start working with Ganymede - but even 24 projects are only a small part of the big Eclipse universe.

So - what do I need in my project, what's not part of Ganymede:

openArchitectureWare 4.3 runs successfully under Ganymede.

EasyBeans - a "foreign" project - I already found the soution how to make it run under 3.4.

Eclipse Riena 1.0.M2 is only available (at the moment) for Eclipse 3.3.

This blog will show you how to make Eclipse Riena run under Ganymede.

The download from Riena provides a target platform containing bundles from Eclipse SDK 3.3, Equinox 3.3 and Riena 10.M2 - also some "external" (Hessian, Log4J, ...).

Please read my blog "PDE Target Platform from different locations (Bugs)" before you go on.Because of these problems we have to build the target platform „manually“ from:

  • Eclipse Platform SDK 3.4 (we're using the SDK as IDE and also as Host for the target platform)f
  • rom Equinox SDK 3.4 some bundles which are not contained in the Platform SDK
  • from Riena M2 - download all *.riena.* Bundles, Hessian and Log4J

  1. Log4J can be used from Riena distribution or from SpringSource Enterprise Bundle Repository.
  2. Problem with org.junit bundle from Platform SDK: If you followed the documentation "Riena Getting started" from Riena wiki and imported the bundle org.eclipse.riena.tests as Plug-in with Source into your workspace then you'll notice some errors, because Ganymede uses org.junit4. Please replace org.junit in project org.eclipse.riena.tests, MANIFEST.MF, Dependencies --> Required Plug-ins with org.junit4 from Eclipse Platform SDK 3.4.

If you create the following folder - structure for your target platform, then you can use my prepared Target Definition Files (see below) and easyly create your target platform.

---- fromEquinoxSDK/
-------- eclipse/
---- fromRienaM2/
-------- eclipse/

Here you can see the content of the plugins - folders:

  1. bundle org.eclipse.equinox.log.1.1.0 from Equinox 3.4 can't be used, because Riena uses a modified version org.eclipse.equinox.log.1.1.0.HEAD containing a class org.eclipse.equinox.log.Logger. Please use the HEAD version from Riena M2 and delete the bundle from Equinox 3.4 inside the folder of the target platform.

Target Definition File (2 different versions)

You can create new Target Definition files using menu File --> New --> Target Definition.

To make it comfortable I've prepared files you can download, unzip and vopy into your workspace:

riena_minimal contains only the smallest set of needed bundles to start a Riena server and to run the Riena Unit tests. Please dont forget to read the documentation Riena getting started from Riena wiki.

Please create a new variable target_riena under Preferences --> Run/Debug --> String Substitutions pointing to the root of the target platform folder.

After opening the file in your workspace you should see:

riena_minimal contains only 64 bundles instead of 126 bundles.

If you click on Set as Target Platform you can start using this target platform and easy change to another target.

Now have fun to start working with Riena 1.0.M2 under Ganymede.

One of my next blogs will show the use of Eclipse Riena together with EasyBeans in Ganymede.

Monday, June 9, 2008

PDE Target Platform from different locations (Bugs)

I'm using Eclipse Riena for my ERP project. Riena's version is actually 1.0.M2 for Eclipse 3.3.

Riena provides an already configured target platform as download - featuring bundles from Eclipse SDK, Equinox and Riena, also some 'foreign' bundles like Hessian, Log4J, ... - but all these bundles are from Eclipse Platform SDK / Equinox 3.3.

So I had to manage the task to build a new target platform designed to run with Eclipse 3.4 (actually version 3.4.RC3).

We need:

  • Eclipse Platform SDK 3.4 (as IDE and target platform)
  • Equinox SDK 3.4 (target platform)
  • Riena - Bundles (target platform)
  • other Bundles from Riena - distribution (target platform)

Target Definition File (Bug using different locations and versions)

From my opinion the easiest (and comfortable) way in such situations is to create a Target Definition File: Menu File --> New --> Target Definition:

As usual I'm working with variables, so the definitions are easy to port into other workspaces and Eclipse versions.

Under Overview I choose / add three locations: Riena, Equinox und SDK.

Under Content I can select which of the plug-ins I want to use in my target platform.

Unfortunately it doesn't work as expected :-(

If you try to add the plug-ins you're seeing only plug-ins from one location - there's no way to decide which plug-ins should be selected from which locations.

Bug 233095 ([target] deal with multiple versions of bundles and different locations)

Target Platform Preferences (Bug using different locations and versions)

The next try: to build the target platform directly using Preferences --> Plug-in Development --> Target Platform:

Using Add... different locations can be selected. If Group plug-ins by location is marked you can see all plug-ins from these locations.

Then its possible to select the bundles you need from each of the 3 locations (Riena, SDK, Equinox). The example above shows 110 of 467 bundles selected.

Doesn't this look nice ? Yes - and after hitting Apply you can start your Riena - Server, run Tests etc.

Now the best you can do is to never restart Eclipse ;-) ... after restarting eclipse you'll see:

Now there are only 53 instead of 110 plug-ins (bundles) selected for your target platform - and the selected ones are other ones then before.

Bug 233096 Preferences - PDE - target platform - after restart selection changed

So because of these two bugs its not possible to build target platforms from some locations if there are multiple versions of plug-ins.

BTW: Please vote for bugs 233095 and 233096, if you also need to be fixed. thx.

this blog in german:

Thursday, June 5, 2008

EasyBeans und Equinox

After the decision to design my upcoming ERP solution as OSGI - Client/Server application using Eclipse Riena (Remoting, ObjectTransactions), Equinox (OSGI) and Hibernate (JPA / ORM) one point remains open: how to integrate EJB (Stateless and Stateful Sessionbeans) ?

The answer: there's a great open source EJB - OSGI solution: EasyBeans.

First step:

Integrate EasyBeans with Eclipse 3.4 + Equinox 3.4. (EasyBeans default OSGI framework is Felix from Apache)

... here's my HowTo:

What do we need: Eclipse Platform SDK, Equinox SDK and Easybeans OSGI - Hibernate-Version. All tests are done and are only running under Eclipse 3.4. At the moment of writing this blog Eclipse 3.4.RC3 is the newest one and EasyBeans OSGI 1.0.0:

We have to differentiate between Eclipse as IDE and as target platform. At first you should install Eclipse Platform SDK as IDE as usual.

If you want to follow this tutorial then you should create a folder structure for the target platform as below.

To make the configuration and installation portable, we define a variable in Eclipse pointing to the root of our target files: ${target_easybeans}.

Then we create the following structure at


No we have to copy the needed plug-ins (bundles).

Which plug-ins you should copy depends on the needs of your project - to be flexible I made examples for two different target platforms: easybeans_target_full and easybeans_target_minimal.

You can download the two target definition files to import them into your Eclipse project: and

easybeans_target_full (complete environment)

please copy into ${target_easybeans}/easybeans_target_full/eclipse/configuration/plugins:

  • all from Eclipse Platform SDK plugins - folder
  • all from Equinox SDK plugins - Ordner, if not contained in Platform SDK - Plugins)
  • from ow2-easybeans-osgi-1.0.0/bundles: all without *.felix.*

easybeans_target_minimal (Target Platform only with needed bundles)

please copy into ${target_easybeans}/easybeans_target_minimal/eclipse/configuration/plugins:

from Equinox SDK:

  • org.eclipse.osgi
  • org.eclipse.equinox.common
  • org.eclipse.equinox.ds
  • org.eclipse.equinox.log
  • org.eclipse.equinox.util
from EasyBeans bundles:
  • ow2-bundles-externals-commons-logging
  • easybeans-core
  • easybeans-component-carol
  • easybeans-component-hsqldb
  • easybeans-component-jdbcpool
  • easybeans-component-joram
  • easybeans-component-jotm
  • easybeans-component-quartz
  • easybeans-agent

if wanted also the examples - bundles from EasyBeans:

  • easybeans-example-osgi
  • easybeans-examples-entitybean
  • easybeans-examples-mdb
  • easybeans-examples-migrationejb21
  • easybeans-examples-security
  • easybeans-examples-statefulbean
  • easybeans-examples-statelessbean
  • easybeans-examples-timerservice


  1. Bundles from EasyBeans (Version 1.0.0) were not named like Equinox - rules: easybeans-core-1.0.0 should be easybeans-core_1.0.0. You can simple rename the bundles (change minus inti underline) or to use the name together with the version if adding bundles to from config.ini. (Bug JIRA)

  2. Bundle easybeans-component-joram-1.0.0 contains a wrong import in MANIFEST.MF: com.scalagent.scheduler This import must be removed. (Bug JIRA)

Its always a good idea to define Target Definition files for your target platforms in Eclipse: Menu File-->New-->Target Definition

After defining the targets you can change to this target with one click from within the target definition file or you do it directly from Preferences - Plug-in Development - Target Platform:

Please check the box (yellow marked). Because we want to build the target platform only using the plug-ins (bundles) stored at target platform location. (see the blog from Chris Aniszczyk)

To start EasyBeans easy ;-) in Eclipse we create OSGI Launch configurations.
Run Configurations...
We need two different OSGI Launch configurations:

  • first launcher uses a configuration file (config.ini in folder configuration), where all bundles were listed under property
  • second launcher runs without using a configuration file - all bundles and arguments are defined directly in the launch configuration

OSGI Framework Launch Configuration with config.ini

There are no bundles selected from target platform, because they are all listed inside config.ini.

The most important program argument is -configuration, you also see the use of the defined variable. Inside this configuration folder you have to place the config.ini.

Content of config.ini:

Its no application - we only want to run these bundles:
  • eclipse.ignoreApp=true
  • osgi.noShutdown=true
Following bundles have to be installed and partly to be started from OSGI framework:
  • osgi.bundles=\
  • org.eclipse.equinox.common@2:start, \
  •, \
  •, \
  • org.eclipse.equinox.ds@start, \
  • org.eclipse.equinox.log@start, \
  • org.eclipse.equinox.util@start, \
  • ow2-bundles-externals-commons-logging-1.0.5@start, \
  • easybeans-core-1.0.0, \
  • easybeans-component-carol-1.0.0, \
  • easybeans-component-hsqldb-1.0.0, \
  • easybeans-component-jdbcpool-1.0.0, \
  • easybeans-component-joram-1.0.0, \
  • easybeans-component-jotm-1.0.0, \
  • easybeans-component-quartz-1.0.0, \
  • easybeans-agent-1.0.0@start, \
  • easybeans-example-osgi-1.0.0, \
  • easybeans-examples-entitybean-1.0.0, \
  • easybeans-examples-mdb-1.0.0, \
  • easybeans-examples-migrationejb21-1.0.0, \
  • easybeans-examples-security-1.0.0, \
  • easybeans-examples-statefulbean-1.0.0, \
  • easybeans-examples-statelessbean-1.0.0, \
  • easybeans-examples-timerservice-1.0.0
Informations about bootdelegation - these packages are loaded from system classloader:
  • org.osgi.framework.bootdelegation=sun.*,com.sun.*
System packages - these packages are exported from the OSGI system bundle and can be imported from other bundles:
  • org.osgi.framework.system.packages=org.osgi.framework; version=1.3.0, \
  • javax.accessibility; \
  • javax.activity; \
  • javax.imageio; \
  • javax.imageio.event; \
  • javax.imageio.metadata; \
  • javax.imageio.plugins.bmp; \
  • javax.imageio.plugins.jpeg; \
  • javax.imageio.spi; \
  •; \
  •; \
  •; \
  •; \
  •; \
  •; \
  •; \
  •; \
  •; \
  •; \
  • javax.naming; \
  •; \
  • javax.naming.event; \
  • javax.naming.ldap; \
  • javax.naming.spi; \
  •; \
  •; \
  • javax.print; \
  • javax.print.attribute; \
  • javax.print.attribute.standard; \
  • javax.print.event; \
  • javax.rmi; \
  • javax.rmi.CORBA; \
  • javax.rmi.ssl; \
  •; \
  •; \
  •; \
  •; \
  •; \
  •; \
  •; \
  • javax.sound.midi; \
  • javax.sound.midi.spi; \
  • javax.sound.sampled; \
  • javax.sound.sampled.spi; \
  • javax.sql; \
  • javax.sql.rowset; \
  • javax.sql.rowset.serial; \
  • javax.sql.rowset.spi; \
  • javax.swing; \
  • javax.swing.border; \
  • javax.swing.colorchooser; \
  • javax.swing.event; \
  • javax.swing.filechooser; \
  • javax.swing.plaf; \
  • javax.swing.plaf.basic; \
  • javax.swing.plaf.metal; \
  • javax.swing.plaf.multi; \
  • javax.swing.plaf.synth; \
  • javax.swing.table; \
  • javax.swing.text; \
  • javax.swing.text.html; \
  • javax.swing.text.html.parser; \
  • javax.swing.text.rtf; \
  • javax.swing.tree; \
  • javax.swing.undo; \
  • javax.xml; \
  • javax.xml.datatype; \
  • javax.xml.namespace; \
  • javax.xml.parsers; \
  • javax.xml.transform; \
  • javax.xml.transform.dom; \
  • javax.xml.transform.sax; \
  •; \
  • javax.xml.validation; \
  • javax.xml.xpath; \
  • org.ietf.jgss; \
  • org.omg.CORBA; \
  • org.omg.CORBA_2_3; \
  • org.omg.CORBA_2_3.portable; \
  • org.omg.CORBA.DynAnyPackage; \
  • org.omg.CORBA.ORBPackage; \
  • org.omg.CORBA.portable; \
  • org.omg.CORBA.TypeCodePackage; \
  • org.omg.CosNaming; \
  • org.omg.CosNaming.NamingContextExtPackage; \
  • org.omg.CosNaming.NamingContextPackage; \
  • org.omg.Dynamic; \
  • org.omg.DynamicAny; \
  • org.omg.DynamicAny.DynAnyFactoryPackage; \
  • org.omg.DynamicAny.DynAnyPackage; \
  • org.omg.IOP; \
  • org.omg.IOP.CodecFactoryPackage; \
  • org.omg.IOP.CodecPackage; \
  • org.omg.Messaging; \
  • org.omg.PortableInterceptor; \
  • org.omg.PortableInterceptor.ORBInitInfoPackage; \
  • org.omg.PortableServer; \
  • org.omg.PortableServer.CurrentPackage; \
  • org.omg.PortableServer.POAManagerPackage; \
  • org.omg.PortableServer.POAPackage; \
  • org.omg.PortableServer.portable; \
  • org.omg.PortableServer.ServantLocatorPackage; \
  • org.omg.SendingContext; \
  •; \
  •; \
  • org.w3c.dom; \
  • org.w3c.dom.bootstrap; \
  • org.w3c.dom.css; \
  •; \
  • org.w3c.dom.html; \
  •; \
  • org.w3c.dom.ranges; \
  • org.w3c.dom.stylesheets; \
  • org.w3c.dom.traversal; \
  • org.w3c.dom.views; \
  • org.xml.sax; \
  • org.xml.sax.ext; \
  • org.xml.sax.helpers; \
  • sun.rmi.server; \
  • sun.rmi.transport; \
  • sun.rmi.registry; \
  • version=1.5.0

Even while testing its a good idea to use an own location for the Configuration Area in the settings of the launch configuration. (We also use our above defined variable here).

Here you can download the launch configuration: easybeans ( in config.file)
And the config.ini for this scenario:

OSGI Framework Launch Configuration without config.ini

In this case you have to select the needed bundles in the launcher.

Please watch the Start Level: equinox.common needs Level 2, all the other bundles get automatically the Default Start Level 4 and then the easybeans.agent with Start Level 5 will be started.

The other bundles from easybeans have set Auto-Start = false, because its the task of the easybeans.agent to start them in the right order.

At programm arguments there's no -configuration - of course all of them now have to be defined as VM Arguments.

Please watch, that -Dorg.osgi.framework.system.packages has to be entered without any spaces - the other arguments are identical to the content of the config.ini in the first scenario.

And here's the launch configuration to Download: easybeans (launch config)

YOU ARE READY - all configuration and installation is done and you can run EasyBeans with different target platforms and different OSGI Framework launch configurations.

Framework is launched.

idState Bundle
0ACTIVE org.eclipse.osgi_3.4.0.v20080521-1400
1ACTIVE org.eclipse.equinox.common_3.4.0.v20080421-2006
2ACTIVE org.eclipse.osgi.services_3.1.200.v20071203
3ACTIVE org.eclipse.equinox.cm_1.0.0.v20080509-1800
4ACTIVE org.eclipse.equinox.ds_1.0.0.v20080427-0830
5ACTIVE org.eclipse.equinox.log_1.1.0.v20080414
6ACTIVE org.eclipse.equinox.util_1.0.0.v20080414
7ACTIVE org.ow2.bundles.ow2-bundles-externals-commons-logging_1.0.5
8ACTIVE org.ow2.easybeans.core_1.0.0
9ACTIVE org.ow2.easybeans.component.carol_1.0.0
10ACTIVE org.ow2.easybeans.component.hsqldb_1.0.0
11ACTIVE org.ow2.easybeans.component.jdbcpool_1.0.0
12ACTIVE org.ow2.easybeans.component.joram_1.0.0
13ACTIVE org.ow2.easybeans.component.jotm_1.0.0
14ACTIVE org.ow2.easybeans.component.quartz_1.0.0
15ACTIVE org.ow2.easybeans.agent_1.0.0
16RESOLVED org.ow2.easybeans.examples.osgi_1.0.0
17RESOLVED org.ow2.easybeans.examples.entitybean_1.0.0
18RESOLVED org.ow2.easybeans.examples.messagedriven_1.0.0
19RESOLVED org.ow2.easybeans.examples.migrationejb21_1.0.0
20RESOLVED org.ow2.easybeans.examples.security_1.0.0
21RESOLVED org.ow2.easybeans.examples.stateful_1.0.0
22RESOLVED org.ow2.easybeans.examples.stateless_1.0.0
23RESOLVED org.ow2.easybeans.examples.timer_1.0.0

Good luck and have fun with EasyBeans. In some days I'll report my experiences how to run EasyBeans and Eclipse Riena together.

this blog in german: