Page History

...

Note: We presume Eclipse 3.2 level as the base. This implies OSGi R4 conventions as the base. But note that Eclipse 3.2 doesn't properly support the "uses" directive in the Export-Package (see following for workaround).

The basic goal is to do things the maven way and reduce custom configuration code in our build, making our build more reliable, understandable, and maintainable over the long run. A second goal is to solve a long-standing problem where the uimaj-ep-runtime plugin, if open in the workspace, made compiling and launching of other plugins that depended on it, not work.

...

A basic principle is to put all the bundle info that normally would go into the MANIFEST.MF part of the Eclpse plugin into the configuration in the POM for the maven-bundle-plugin, and use that to generate the manifest.mf. This gives just one place to maintain this information. The plugin.xml (used to describe extension points) is still needed if the plugin defines extension points. Some plugins have "blank" plugin.xml - these can just be deleted. The build.properties file is not used, either. (it is used only for Eclipse building the plugins, and we instead have Maven do that).

• A downside to this is that the process for checking out plugin-projects and getting them to work in Eclipse is now: 1) check out, 2) mvn install (needed to create the MANIFEST.MF), mvn eclipse:eclipse, (and then, if needed, "import" into Eclipse workspace). Steps 2 and 3 can be done in one command: mvn install eclipse:eclipse.

What does the maven-bundle-plugin do?

...

This is a library plugin, consisting of jars from other projects. It is built using the maven-bundle-plugin capabilities to specify what packages to export, using the <_exportcontents> directive. This directive avoids actually including those packages in the bundle as direct classes, (versus using the normal <Export-Package> directive), because a later instruction, <Embed-Dependency>, specifies using the dependency information to embed the Jar files maven builds for those, in the bundle being built. Since the jars already have the packages, we use <_exportcontents> to avoid duplicating these contents.

The inline=true flag is set when embedding dependencies, to avoid having the bundle jar contain within itself, other jars. This flag puts the contents of the inner jars into the containing jars. This is needed because the OSGi or Eclipse mechanisms doesn't see exports coming from these jars within jars. See the statements about "Unzipping JARs" in the Eclipse Help.

One thing the bundle plugin does is to follow dependency chains in the things it's including. When the uimaj-adapter-soap was included, the bundle plugin determined this needed the axis jars; these are not however part of our distribution. Because of this, the uimaj-adapter-soap dependency is commented out at this point. It's left in as a comment, in case a user wants to build a version of this with the axis files included.

...

These dependencies allow both maven and Eclipse to compile the source of the plugins.

The bundle will create mechanism in the maven-bundle-plugin that creates "uses" clauses for packages from the dependencies that it actually uses. These help insure correct "wiring" of the right versions of classes, in the case where multiple versions are presentis turned off, because that feature isn't properly supported in Eclipse 3.2. Therefore, if there are multiple versions of these packages that are present, be aware that mis-wiring may occur. For more on this, see http://underlap.blogspot.com/2007/10/osgi-type-safety-and-uses-directive.html

...