Dave Reynolds wrote:
On Thu, 2011-09-08 at 20:34 +0100, Paolo Castagna wrote:
Dave Reynolds wrote:
On Tue, 2011-09-06 at 13:06 +0100, Andy Seaborne wrote:
[Great set of thoughts.]
== Goals
[snip]
+ A single download zip file for using Jena as a library
+ A single jar file for using Jena as a library
+1 for goals overall and for the notion of a single jar.
Hi Dave,
just to make sure I understand your position.
Do you mean "a single jar" in addition to separate jars (one for each of the
Jena modules, for example: tdb-x.y.z.jar, arq-x.y.z.jar and maybe new jars
such as riot-x.y.z.jar, atlas-x.y.z.jar and a small jena-core-x.y.z.jar
(exact list yet to be decided))?
Yes, in addition, which is what I took Andy to be proposing.
Great.
The module jars need only be in Maven repositories but they should
certainly be available. No argument there.
Good.
What's not clear to me (in relation to the Apache release process) is how and
when we publish artifacts to the Maven Apache repository and if we can publish
a module without releasing all the other modules. Maybe mentors can help me
understand this.
A similar argument (i.e. better modularization) is what pushed projects such
as Any23 away from Jena in favour of Sesame, for example. I can relate to that
and I understand why.
Not sure that modularization is being used in the same sense there -
that seems more about API abstractions.
Ack.
I'd like (as in, I would put work into this) to also have osgi support.
Suggest:
o the jena-one-jar would also be marked as an OSGI bundle (easy to do
via maven bundle plugin)
We don't use OSGI, but if it's easy to do and it help others, why not?
o a third top level download, jena-complete, which is the jena-one-jar
plus dependent jars (i.e. xerces, slf4j/log4j etc) packaged as an single
jar/OSGI bundle.
The latter is not *necessary* for OSGi support but the way we/I
currently work with OSGi makes it easier to have reasonably chunky
self-contained bundles than do the fine grain dependency management at
the OSGi level.
I am not an expert of OSGi, however a chunky jena-one-jar including all
the third party dependencies is something I would say "unusual" and certainly
something we would not use. I am not so sure who would find that useful.
But, maybe I am wrong.
There are plenty of precedents.
For example, velocity also offers (or at least used to offer, haven't
checked recently) a velocity-complete.jar for ease of use by
non-Mavenites.
JRuby offers a jruby-complete which which also includes the jruby HOME
files thus giving you a complete ruby-in-a-jar. That jar is also an OSGi
component which means we can get full Ruby support including driving
Jena from ruby by dropping a single jar into our OSGi framework. Works
really nicely.
The "Swiss army knife of OSGi" is bnd which is again a single jar which
contains all its dependencies. Magically that jar can be used for
command line operation ("java -jar bnd.jar") and as an OSGi component in
any OSGi framework *and* as a full Eclipse plugin.
The last time that OSGi packaging of Jena came up on jena-dev the
solution eventually adopted by the original requester was a
self-contained jar (as evidenced by the pom.xml they posted).
Etc.
Ack
This can also be used via "java -jar jena-complete.jar ..." to run any
of the command line utilities which would save some support list load on
classpath advice :)
Support cost on classpath issues seems to be not much (maybe it's better
documentation, maybe people are learning how to use Maven, who knows).
However, a single jar is really useful to run command line utilities or
applications such as Fuseki.
Exactly. A simple download and run, no configuration, no tearing your
hair out over Maven, is a nice option for some users in some situations,
and essentially a free side effect of doing a self-contained bundle.
Hopefully, you are not tearing your hair out over Maven because of Jena's
pom.xml (even if we have a few problems at the moment with *-test.jar if
I remember correctly). Those problems will get fixed before you get bald. ;-)
So, I do not oppose to this, but I would not like to lose the opportunity
for a better modularization of Jena.
I see no negative impact on the modularization.
Great.
I believe we can have "single jar" and separate modules (and from what you
wrote below) it seems we are on the same page on this.
Indeed we are.
All clear now.
Paolo
Dave
