Looking at Maven downloads is not fair as most OSGi users are not using Maven as build system, but use OSGi directly, e g. with Eclipse, and get their bundles in various ways.
One example of an OSGi project who uses owlapi and sesame (but not Jena I think) is Protégé the ontology editor. In Taverna we use OSGi with Maven build, because we don't want to move out of Maven's ecosystem (and changing build system is a big job ;) If you compare Maven jars now to 5 years ago I think you will find a significant increase in projects that are also OSGi bundles (at mvnrepository.com look for type BUNDLE). The reason is simple, it is usually just a matter of adding the right META-INF settings which don't impact "regular" Java/Maven users . Agree that there should not be any big reason to not use the bundle setting on all of jena-libs - the maven-bundle-plugin does a good enough job when you avoid the workarounds. Two things holding back is xerces and xmlapi, but we could shade them as we do with guava (thus calming the worry about using impl. classed in xerces) or add their Jars to jena-core as is done in jena-osgi currently. Shading will probably avoid most conflicts as shown in Clerezza-Jena case. Another is the odd Class.forName, if we still have any, from jena-core to jena-arq. This should be changed anyway as it is not really good practice. My apologies for not maintaining the jena-osgi-test - that particular testing approach was new to me as well so I don't know how to debug it. It was mainly needed to verify that the jena-osgi repackaging didn't break anything (e.g. this bug). One last thing is that jena-arq etc depend on httpclient, which has a similar separate httpclient-osgi variant, which unfortunately in Maven depends on the regular httpclient JARs (without our scope:provided trick) - jena-osgi uses ignores to avoid downstream OSGi-Maven users from getting duplicate httpclients. It would be possible to switch to use the httpclient-osgi Maven dependency instead all over in Jena, but this could surprise existing Maven users who could end up with duplicate httpclient implementations om their classpath in different versions if other dependencies use httpclient. This is not a large issue as I said most OSGi projects don't rely on Maven dependency transitivity blindly (and they could always ignore locally those extra dependencies). Assuming we change jena-core/tdb/arq/iri to be bundles themselves but still depending on regular httpclient, perhaps one way to simplify Jena use for OSGi-Maven users is for jena-osgi to remain as a dependency marker pom only, with appropriate <ignores>. But this thread should be tracked as a new Jira issue! :)) On 11 Feb 2016 16:44, "A. Soroka (JIRA)" <[email protected]> wrote: > > [ > https://issues.apache.org/jira/browse/JENA-1139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15142908#comment-15142908 > ] > > A. Soroka commented on JENA-1139: > --------------------------------- > > The {{jena-osgi}} bundle, but only to avoid the kind of thing that went on > here: CLEREZZA-1004, and because we will not commit our users to a specific > OSGi framework/container. We would certainly rather just pull in ordinary > Jena JARs (that happen to include the OSGi metadata). Is there some reason > I am missing that we can't equip those JARs with said metadata? Is it just > a matter of who's got the time? > > > jena-osgi does not initialize all modules > > ----------------------------------------- > > > > Key: JENA-1139 > > URL: https://issues.apache.org/jira/browse/JENA-1139 > > Project: Apache Jena > > Issue Type: Bug > > Components: OSGi > > Affects Versions: Jena 3.0.1 > > Reporter: Stian Soiland-Reyes > > Assignee: Andy Seaborne > > Fix For: Jena 3.1.0 > > > > Attachments: Screen Shot 2016-02-11 at 10.02.50.png > > > > > > As discovered in TAVERNA-892 the jena-osgi of Jena 3.0.1 > > seems to have not merged correctly > > META-INF/services/org.apache.jena.system.JenaSubsystemLifecycle > > which breaks the new Jena initialization - only TDB is initialized - but > TDB depends on ARQ already being initialized (to get its context). > > {code} > > stain@biggie:~/.m2/repository/org/apache/jena/jena-osgi$ unzip > ./3.0.1/jena-osgi-3.0.1.jar > META-INF/services/org.apache.jena.system.JenaSubsystemLifecycle > > Archive: ./3.0.1/jena-osgi-3.0.1.jar > > inflating: > META-INF/services/org.apache.jena.system.JenaSubsystemLifecycle > > stain@biggie:~/.m2/repository/org/apache/jena/jena-osgi$ cat > META-INF/services/org.apache.jena.system.JenaSubsystemLifecycle > > org.apache.jena.tdb.sys.InitTDB > > {code} > > So basically only the last JenaSubsystemLifecycle file survives when > shading jena-core, jena-arq, jena-tdb, jena-iri with Embed-Dependency and > inline=true. > > The equivalent of the Maven Shade plugin's ServicesResourceTransformer > would be able to merge these. > > > https://maven.apache.org/plugins/maven-shade-plugin/examples/resource-transformers.html#ServicesResourceTransformer > > but I'm not sure how this can be done with the bundle plugin. I guess > it could be overridden with its own src/main/resources/META-INF/services/ > file in jena-osgi as well - but then it needs maintenance. > > > > -- > This message was sent by Atlassian JIRA > (v6.3.4#6332) >
