jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bertrand Delacretaz <bdelacre...@apache.org>
Subject Re: [jr3] One Project
Date Tue, 30 Nov 2010 12:46:09 GMT
Hi,

(I'm not a developer here, so consider this peanut gallery talk)

On Tue, Nov 30, 2010 at 11:42 AM, Thomas Mueller <mueller@adobe.com> wrote:
> ....I think reducing the number of
> projects for Jackrabbit 3 will result in a simpler, more standard build....

Reducing the number of Maven modules probably makes sense, but "just
one module" is probably too much of a restriction. Granularity is a
hard problem, and extreme views on that usually don't work, in my
experience.

> ...If we include all dependencies (such as Apache Commons jar files) you
> would need a special class loader, right? Otherwise there may be conflicts
> with if somebody already uses a different version of a Apache Commons
> library that Jackrabbit also uses. That would be quite complex I guess, so
> I wouldn't do that. Instead, I would just concentrate on having as few jar
> files as possible...

OSGi solves that problem nicely, and the base framework is not heavy at all.

Having a small set of OSGi-friendly (but maybe not OSGi-based, for
broad use) jars for jr3, and combining them with an OSGi runtime for
the out-of-the-box jr3 runnable jar, might be the best way to solve
this.

>... I think it would be an advantage if we could reduce the
> number of dependencies however (maybe even make Lucene optional - that
> would allow to use Jackrabbit on Android)....

Agree about making indexing/search pluggable - I have a few use cases
in mind (like using Solr or what Apache Stanbol is starting to create)
where alternate/multiple indexing systems would add a lot of value.

BTW, is there an agreed upon set of goals for jr3 somewhere?

There have been discussions on this list, but if jr3 development is
about to ramp up now might be a good time to make sure all developers
are on the same page w.r.t development goals and constraints.

-Bertrand

Mime
View raw message