lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael McCandless <>
Subject Re: Modularization
Date Mon, 23 Mar 2009 15:10:35 GMT
Michael Busch <> wrote:

>> And I don't think the sudden separation of "core" vs "contrib"
>> should be so prominent (or even visible); it's really a detail of
>> how we manage source control.
>> When looking at the website I'd like read that Lucene can do hit
>> highlighting, powerful query parsing, spell checking, analyze
>> different languages, etc.  I could care less that some of these
>> happen to live under a "contrib" subdirectory somewhere in the
>> source control system.
> OK, so I think we all agree about the packaging. But I believe it is
> also important how the source code is organized. Maybe Lucene
> consumers don't care too much, however, Lucene is an open source
> project. So we also want to attract possible contributors with a
> nicely organized code base. If there is a clear separation between
> the different components on a source code level, becoming familiar
> with Lucene as a contributor might not be so overwhelming.


We want the source code to be well organized: consumability by Lucene
developers (not just Lucene users) is also important for Lucene's
future growth.

> Besides that, I think a one-to-one mapping between the packaging and
> the source code has no disadvantages. (and it would certainly make
> the build scripts easier!)


So, towards that... why even break out contrib vs core, in source
control?  Can't we simply migrate contrib/* into core, in the right

>> Could we, instead, adopt some standard way (in the package
>> javadocs) of stating the maturity/activity/back compat policies/etc
>> of a given package?
> This makes sense; e.g. we could release new modules as beta versions
> (= use at own risk, no backwards-compatibility).

In fact we already have a 2.9 Jira issue opened to better document the
back-compat/JDK version requirements of all packages.

I think, like we've done with core lately when a new feature is added,
we could have the default assumption be full back compatibility, but
then those classes/methods/packages that are very new and may change
simply say so clearly in their javadocs.

> And if we start a new module (e.g. a GSoC project) we could exclude
> it from a release easily if it's truly experimental and not in a
> release-able state.


>> So I think the beginnings of a rough proposal is taking shape, for

>>   1. Fix web site to give a better intro to Lucene's features,
>>       without exposing core vs. contrib false (to the Lucene
>>       consumer) > distinction
>>   2. When releasing, we make a single JAR holding core & contrib
>>       classes for a given area.  The final JAR files don't contain a
>>       "core" vs "contrib" distinction.
>>   3. We create a "bundled" JAR that has the common packages
>>       "typically" needed (index/search core, analyzers, queries,
>>       highlighter, spellchecker)
> +1 to all three points.


So I guess I'm proposing adding:

   4. Move contrib/* under src/java/*, updating the javadocs to state
       back compatibility promises per class/package.

I think net/net this'd be a great simplification?


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message