views:

154

answers:

3

To produce a bundle from source using a tool such as javac, you need to provide it with a linear classpath. Unfortunately, it won't work in some situations still perfectly legal from an OSGi point of view:

  • dependencies with embedded JAR in them;

  • same packages contained by different dependencies.

Since javac doesn't understand OSGi metadata, I won't be able to simply but the dependencies in a classpath. A finer package grained approach seems necessary.

How this problem is addressed by people using OSGi in an automated process (continuous integration)? Strangely, there is a lot of resources on the web on how to create bundle JAR (creating the metadata, creating the JAR) provided you have the classes/inner JAR to put inside, but very few things on how actually get theses classes compiled.

Let's take an example: my bundle need two other bundles to compile, both contains Xerces as an embedded JAR but in two different and incompatible versions. It is not a problem since only one of them export some packages of xerces my bundle is in turn importing. Not a very clean situation maybe but something that could "legaly" happen in an OSGi container without problem.

Now, how can I compile it ? I can't put the two dependencies in my classpath (the embedded Xerces JAR won't be found by javac), I can't flatten then either (the two versions of Xerces will collide and maybe the one not exported would be first). If the ony solution is to create a "classpath" on a package level, not on a full bundle scale, javac is not usable at all.

A: 

Java classes are compiled by javac, this implies: in order to compile a bundle you have to include all bundles you depend on in the classpath. You're right that javac isn't OSGi aware. So you need other tools for automation.

To see how this is accomplished you could look into Felix which implements an OSGi R4 Service Platform.

An OSGi bundle is usually packed by ant or maven, which are supported by eclipse. Using eclipse the dependencies are configured in the projects settings tab "plugin-dependencies".

A good example how to setup an OSGi project in eclipse is Sherlog

stacker
A: 

Javac is required to build any java file into a classfile. OSGI bundles are like any other java bundling archive a collection of class files and a manifest which several mandatory self explanatory entries inside a JAR file.

If you want your bundle to function correctly then it must have all its dependencies satisfied. If you wish to export some of its services or classses then you must also declare these in a similar fashion. Once you understand the concepts the OSGI specific headers within the archive make sense.

mP
Maybe I'm wrong, but the Maven plugins created to cope with OSGi (m2eclipse or the one from Felix) still rely on javac in the end, giving it a linear classpath to feed on.
Chatanga