You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

There is a new maven plugin, maven-bundle-plugin, which we can use in place of custom assembly steps and ant scripts, to build eclipse plugins. There is a way to do the uimaj-ep-runtime plugin so that it works correctly when it is open in the workspace, too. This tip describes the approach and design rationale.

Note: We presume Eclipse 3.2 level as the base. This implies OSGi R4 conventions as the base.

The basic goal is to do things the maven way and reduce custom configuration code in our build. This makes 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.

The basic information for how to do this comes from the maven-bundle-plugin documentation: http://felix.apache.org/site/maven-bundle-plugin-bnd.html

This plugin supports "library project" plugins which are just collections of other jars, put into a plugin - exactly what our uimaj-ep-runtime plugin is.

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. 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 Eciipse building the plugins, and we instead have Maven do that).

Running the maven-bundle-plugin takes the information in the POM and uses it to construct the MANIFEST.MF file. The <dependencies> are used to augment where the maven-bundle-plugin searches for packages to export; however, it is the configuration information in the maven-bundle-plugin that specifies what to do, specifically.

The uimaj-ep-runtime plugin

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 avoids actually including those packages in the bundle as direct classes, versus using <Export-Package> directive. The reason to exclude these, is that another later directive, <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 uimaj-adapter-soap dependency is commented out at this point, because it would seem it could not work - it, in turn, depends on axis files that we don't distribute. It's left in as a comment, in case a user wants to build a version of this with the axis files included.

One of the benefits of using the maven-bundle-plugin is increased reliability - it "discovered" this dependency within the uimaj-adapter-soap on axis.

Making the uimaj-ep-runtime plugin work in Eclipse when open

Previously, this plugin had an empty src and empty target/classes because all the source/class files were in other projects, it just was a collector of their Jars. This makes Eclipse think it's empty, though, when it's open. To fix this, the <Embed-Dependency> directive actually copies the dependency jar into the

  • No labels