On Tue, Nov 30, 2010 at 1:46 PM, Bertrand Delacretaz <bdelacre...@apache.org> wrote: > Hi, > > (I'm not a developer here, so consider this peanut gallery talk) > > On Tue, Nov 30, 2010 at 11:42 AM, Thomas Mueller <muel...@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,
so you can have multiple versions of the same jar/bundle concurrently deployed in the same osgi container? > 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 >
