lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Busch <busch...@gmail.com>
Subject Re: Modularization
Date Sat, 21 Mar 2009 21:38:53 GMT
On 3/21/09 1:36 PM, Michael McCandless 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.

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!)
>> But I think we should still have "main modules", such as core,
>> queries, analyzers, ... and separately e.g. "sandbox modules?", for
>> the things currently in contrib that are experimental or, as Mark
>> called them, "graveyard contribs" :) ... even though we might then
>> as well ask the questions if we can not really bury the latter
>> ones...
>>      
>
> 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).

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

> 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