lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael McCandless <luc...@mikemccandless.com>
Subject Re: Modularization
Date Mon, 23 Mar 2009 15:10:35 GMT
Michael Busch <buschmic@gmail.com> 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.

+1

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!)

Right.

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

>> 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.

Right.

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

>>   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.

OK.

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?

Mike

---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org


Mime
View raw message