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.
The module jars need only be in Maven repositories but they should
certainly be available. No argument there.
> 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.
> > 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.
> > 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.
> 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.
> 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.
Dave
