lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From DM Smith <>
Subject Re: Modularization (was: Re: New flexible query parser)
Date Sat, 21 Mar 2009 15:43:02 GMT

On Mar 21, 2009, at 7:23 AM, Grant Ingersoll wrote:

> On Mar 21, 2009, at 11:26 AM, Michael McCandless wrote:
>> What if (maybe for 3.0, since we can mix in 1.5 sources at that
>> point?) we change how Lucene is bundled, such that core queries and
>> contrib/query/* are in one JAR (lucene-query-3.0.jar)?  And
>> lucene-analyzers-3.0.jar would include contrib/analyzers/* and
>> org/apache/lucene/analysis/*.  And lucene-queryparser.jar, etc.
> Since we are just talking about packaging, why can't we have both/ 
> all of the above?  Individual jars, as well as one "big" jar, that  
> contains everything (or, everything that has only dependencies we  
> can ship, or "everything" that we deem important for an OOTB  
> experience).  I, for one, find it annoying to have to go get  
> snowball, analyzers, spellchecking and highlighting separate in most  
> cases b/c I almost always use all of them and don't particularly  
> care if there are extra classes in a JAR, but can appreciate the  
> need to do that in specific instances where leaner versions are  
> needed.  After all, the Ant magic to do all of this is pretty  
> trivial given we just need to combine the various jars into a single  
> jar (while keeping the indiv. ones)
> If there is a sense that some contribs aren't maintained or aren't  
> as "good", then we need to ask ourselves whether they are:
> 1. stable and solid and don't need much care and are doing just fine  
> thank you very much, or,
> 2. need to be archived, since they only serve as a distraction, or
> 3. in need of a new champion to maintain/promote them

 From a user's perspective (i.e. mine):
I like the idea regarding having more jars. Specifically, I'd like a  
jar that was devoted alone to reading an index. Ultimately, I'd like  
it to work in a J2ME environment, but that is entirely a different  

There are parts that are needed for both reading and writing  
(directory, analyzers, tokens, and such). And there are parts dealing  
with writing.

There is a distinction between core and contrib regarding backward  
compatibility and quality (perhaps perceived quality).

To me the hardest part in wrapping my head around contrib is that I am  
not clear on why something is in contrib, what it can do, whether it  
is just an example, an alternate way of doing something or it is  
useful exactly as provided.

There are parts of contrib that I see as essential to my application  
(pretty much Grant's list), that I can use as is. While there are many  
different applications of Lucene, my guess is that a non-trivial  
application of Lucene needs to use various contribs. Some contribs are  
high quality and I think deserve the kind of attention that core gets.

What I'd like to see is not more stuff move into core from contrib.  
But rather that we have two levels of contrib: One recommended for use  
and maintained at the same level as core. The other is stuff that is  
"use if you find it useful, and at your own risk". That is, as it is  

I understand the desire to have one jar do it all. Nothing wrong with  
having that too, perhaps lucene-essentials.jar that holds all useful,  
recommended, highly maintained, well-explained stuff.

As to the whole question of the oobe for reviewers, today, it is what  
does Lucene-core.jar do. With more jars it would be what does this  
core collection of jars do or what does lucene-esssentials.

-- DM Smith

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

View raw message