THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
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 is no longer a problem because the (maven) dependencies on the runtime plugin in other projects were changed to instead depend on the individual components. Some messages in the maven world suggest this is a better thing to do.
When these plugins get built, the builder uses the depenedencies when looking for packages to export or just include. But only those packages that are listed in the Export-Packages or Private-Packages will be put into the bundle that is built. So it doesn't hurt to have these project "depend" in the maven sense on parts of uimaj-ep-runtime that they depend on.
The bundle will create "uses" clauses for packages from the dependencies that it actually uses. See next sectionl
Require-Bundle vs Import Packages vs the uses= clause in Export-Package
The Eclipse-built manifests put in Require-Bundle entries for things you list in as bundle dependencies. You can continue to do this, also, using the maven-bundle-plugin because it will just pass thru any instructions that start with capital letters like "Require-Bundle" to the manifest.
However, the default is to not do this, but to put the dependencies at a finer granularity than a bundle, using the "uses-" clause in the Export-Package and Private-Package directives. These are imports that OSGi is free to supply from any bundle that exports them. Of course, in our main use case, there is only one such bundle, and everything should work.
The Import-Package directive is there to allow specifying more details about the particulars of the package you want to import, such as a particular version, or a particular bundle it must come from. Eclipse doesn't use them, and we don't either (at the moment).