On 05/11/14 12:36, Stian Soiland-Reyes wrote:
The main reasons I see for keeping separate modules:
Good list - let me see
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.
No longer happens for jena-* modules. We could be more formal about he
groups of modules that go together.
b) Dependency requirements - A requires significantly different set of
dependencies than B - e.g. pulls in the OWLAPI
There is some argument for
jena-ogsi-core = iri+core+arq
and no TDB.
c) Separation of concern - A is the API, B is the implementation.
Almost nobody should use B directly.
Valuable if there are multiple independent implementations of A,
otherwise it's more internal/development style, I would say.
d) Avoiding spaghetti - B depends on A and C, C depends on A
Yes, well, ...
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
The latter is nearly fixed - logging is needed by commands so have a
separate jena-cmds and it should "just work"(tm).
[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..
Yes - for HTTP stuff and json-ld mainly.
And jcl-over-slf4j to cope with the different choices of dependencies in
their logging ... :-(
Andy
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/
