OSGi builds probably not quite right

[Marshall Schor <ms...@schor.com>]

The OSGi builds for addons now have a lib/ containing the Jars.

Because of a suspicion that OSGi packaging won't work unless the uimaj-core jar
is included, the build was altered to include this jar in the lib/, and the
bundle classpath augmented to cover this.

However, the BND program is "deducing" that the uima-core packages need to be
imported.  Because of this, the rules for class loaders in OSGi say the loaders
will "prefer" an instance of a class coming from a wired-in import, over the
same class in the bundle classpath ( Section 4.7 in Rel 3 of osgi spec, or 3.9.4
in Rel 4.3 of OSGi Service Platform Core Specification).

To make UIMA work without "buddy" loading, the UIMA framework classes have to be
under the same class loader I think as the annotator classes, which would happen
only if the uima-core packages were *not* wired to the OSGi add-on bundle.

A fix which seems to work is to tell the BND that the uima-core jar classes are
part of the internal classes.  Normally that's done by making this a
compile-time dependency.  But if that's done, the other builds (non OSGi - for
the normal binary assembly, and PEAR packagings) are wrong because they should
*not* contain the uima-core packages.

It's possible to tell BND about additional jar files using the Include-Resources
directive - I've tried that and it works (the uima core packages are no longer
"imported" in the generated manifest).  I'm waiting for the uima-build-resources
release to finish - before checking in this change (because it depends on this
release :-) ).

-Marshall