On 10 September 2015 at 18:13, [email protected] <[email protected]> wrote:
> If this is a matter of "just a couple of lines in the manifest file" cannot a 
> patch be created to do that in Jena itself? Are there inter-module dependency 
> issues that make that difficult?


In theory just setting

<packaging>bundle</packaging>

and using the maven-bundle-plugin
is enough to auto-generate the correct META-INF metadata for OSGi.
This can be customized (as we do for the apache-jena-osgi/jena-osgi
module).

One complication is if the external dependencies are OSGi or not -
httpclient is one tricky one as it has done the same as Jena and
provided a separate wrapper httpclient-osgi (and httpcore-osgi) -
however the way they did this with Maven means that just using it as a
dependency would still pull in a dependency on the regular httpclient
library. So if you are a non-OSGi user you would then see the
httpclient classes in two JARs - which with Maven version resolution
could easily become in mismatched versions.

Ironically httpclient-osgi does not depend on httpcore-osgi - so the
one dependency that it truly need isn't stated in its pom.


In jena-osgi I therefore excluded all those deeper dependencies:

See 
https://github.com/apache/jena/blob/master/apache-jena-osgi/jena-osgi/pom.xml#L165

To avoid Jena-Maven-OSGi users the same issue, I similarly here
slightly misused the <scope>provided</scope> for the dependencies that
are not to be dependencies of the final jena-osgi JAR, but which are
shadowed inside.
https://github.com/apache/jena/blob/master/apache-jena-osgi/jena-osgi/pom.xml#L107


If we move to <packaging>bundle</packaging> then we should get
httpclient folks to sort out their poms upstream so we can rely on
them in a cleaner fashion across Jena. (or put this exclusion rule
into <dependencyManagement> of jena-parent) - I don't think
copy-pasting that big <exclusion> block around anything that directly
or indirectly requires things like httpclient is good.

Ideally they should also move to <packaging>bundle</packaging> and
avoid *-osgi, which would of course simplify things.


There are other potential issues as Class.forName() which the current
jena-osgi is narrowly cheating around by effectively making a single
class loader for all of Jena (including as Reto pointed out, TDB etc)





-- 
Stian Soiland-Reyes
Apache Taverna (incubating), Apache Commons RDF (incubating)
http://orcid.org/0000-0001-9842-9718

Reply via email to