The main reasons I see for keeping separate modules: a) Version independence - A moves at a different pace than B, say B v2.0 break things for users of B v.1.3 - while A v1.4 users should not care. b) Dependency requirements - A requires significantly different set of dependencies than B - e.g. pulls in the OWLAPI c) Separation of concern - A is the API, B is the implementation. Almost nobody should use B directly. d) Avoiding spaghetti - B depends on A and C, C depends on A
FYI, here's the dependency graphs: jena-core [INFO] org.apache.jena:jena-core:jar:2.12.2-SNAPSHOT [INFO] +- junit:junit:jar:4.11:test [INFO] | \- org.hamcrest:hamcrest-core:jar:1.3:test [INFO] +- org.slf4j:slf4j-api:jar:1.7.6:compile [INFO] +- org.apache.jena:jena-iri:jar:1.1.2-SNAPSHOT:compile [INFO] +- xerces:xercesImpl:jar:2.11.0:compile [INFO] | \- xml-apis:xml-apis:jar:1.4.01:compile [INFO] +- org.slf4j:slf4j-log4j12:jar:1.7.6:compile [INFO] \- log4j:log4j:jar:1.2.17:compile [INFO] org.apache.jena:jena-arq:jar:2.12.2-SNAPSHOT [INFO] +- org.apache.jena:jena-core:jar:2.12.2-SNAPSHOT:compile [INFO] | +- org.apache.jena:jena-iri:jar:1.1.2-SNAPSHOT:compile [INFO] | \- xerces:xercesImpl:jar:2.11.0:compile [INFO] | \- xml-apis:xml-apis:jar:1.4.01:compile [INFO] +- org.apache.jena:jena-core:jar:tests:2.12.2-SNAPSHOT:test [INFO] +- org.apache.httpcomponents:httpclient:jar:4.2.6:compile [INFO] | +- org.apache.httpcomponents:httpcore:jar:4.2.5:compile [INFO] | \- commons-codec:commons-codec:jar:1.6:compile [INFO] +- com.github.jsonld-java:jsonld-java:jar:0.5.0:compile [INFO] | +- com.fasterxml.jackson.core:jackson-core:jar:2.3.3:compile [INFO] | \- com.fasterxml.jackson.core:jackson-databind:jar:2.3.3:compile [INFO] | \- com.fasterxml.jackson.core:jackson-annotations:jar:2.3.0:compile [INFO] +- org.apache.httpcomponents:httpclient-cache:jar:4.2.6:compile [INFO] +- org.apache.thrift:libthrift:jar:0.9.1:compile [INFO] | \- org.apache.commons:commons-lang3:jar:3.1:compile [INFO] +- org.slf4j:jcl-over-slf4j:jar:1.7.6:compile [INFO] +- org.apache.commons:commons-csv:jar:1.0:compile [INFO] +- junit:junit:jar:4.11:test [INFO] | \- org.hamcrest:hamcrest-core:jar:1.3:test [INFO] +- org.slf4j:slf4j-api:jar:1.7.6:compile [INFO] +- org.slf4j:slf4j-log4j12:jar:1.7.6:compile [INFO] \- log4j:log4j:jar:1.2.17:compile jena-iri [INFO] org.apache.jena:jena-iri:jar:1.1.2-SNAPSHOT [INFO] +- junit:junit:jar:4.11:test [INFO] | \- org.hamcrest:hamcrest-core:jar:1.3:test [INFO] +- org.slf4j:slf4j-api:jar:1.7.6:compile [INFO] +- org.slf4j:slf4j-log4j12:jar:1.7.6:compile [INFO] \- log4j:log4j:jar:1.2.17:compile jena-arq seems to pull in quite a fair bit more than jena-core.. On 5 November 2014 12:13, Andy Seaborne <a...@apache.org> wrote: > What I (still) don't understand is the use case for separate bundles per > separate jena module. (not that I'm an OSGi user ATM) > > The contract around a Jena release is that the whole thing works together. > There aren't independent releases of ARQ and core, say. It has been done as > independent jars a while ago but the net result was just version confusion. > That's also why they have the same version numbers nowadays. The separation > of modules is "internal" rathe rthan an external contract. > > And yet people still manage to create mixed up combinations of jars so I > wonder if the main jar ought not to be one combined jena jar (c.f. > apache-jena-libs except that's a POM). Keep the dependencies separate. > > Is there a real need for separate jena-* nowadays? Or is it just a source > of confusion and mistakes? > > Andy > > > > On 04/11/14 10:54, Reto Gmür wrote: >> >> Hi >> >> In the clerezza project we have been wrapping jena for a while as OSGi >> bundles. >> >> Recently it got split up into different bundles. The source (i.e. the >> poms) >> can be seen here: >> >> https://github.com/apache/clerezza/tree/master/ext >> >> Cheers, >> Reto >> >> On Sat, Nov 1, 2014 at 2:26 AM, Stian Soiland-Reyes < >> soiland-re...@cs.manchester.ac.uk> wrote: >> >>> I would like to hear from your experience of a custom-wrapped bundle >>> what you decided to include or not. >>> >>> See my other email message in this thread.. >>> >>> Basically in short: >>> >>> >>> >>> http://build.mygrid.org.uk/ci/job/jena-bundle/21/org.apache.jena$jena-osgi/ >>> >>> >>> >>> http://repository.mygrid.org.uk/artifactory/ext-snapshot-local/org/apache/jena/jena-osgi/2.12.2-SNAPSHOT/ >>> >>> >>> http://repository.mygrid.org.uk/artifactory/ext-snapshot-local/org/apache/jena/jena-parent/12-SNAPSHOT/ >>> >>> >>> > -- Stian Soiland-Reyes, myGrid team School of Computer Science The University of Manchester http://soiland-reyes.com/stian/work/ http://orcid.org/0000-0001-9842-9718
