Page History

...

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).