lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Otis Gospodnetic <>
Subject Re: Core vs Contrib
Date Wed, 21 Jun 2006 15:58:33 GMT

Judging from a cursory look at LUCENE-406, that should be in the core (my reasoning was: well,
if it's simply the direct opposite of what's already in the core, it makes sense to sit right
next to its opposite in the core with the "opposite name", or else who'll think to look in
contrib, especially contrib/misc).

We currently have only 2 places for code - core and contrib.  Where new stuff should go can
be discussed, but I think it's almost always very obvious.

I think of this as:
code/fundamental - what all programs use by using the Lucene API
contrib/useful - what many programs might use - current contrib

I think "mostly examples and code that is not quite ready to be classed as useful"-type code
typically doesn't get committed.  Sometimes it sits in JIRA and rots, but typically if code
is not useful people don't contribute it, or at least that's what I've observed.


----- Original Message ----
From: Chris Hostetter <>
To: Lucene Dev <>
Sent: Wednesday, June 21, 2006 3:43:23 AM
Subject: Re: Core vs Contrib

: I think that it might be good to define 3 levels:
: fundamental - what all programs probably will use
: useful - what many programs might use
: contrib - mostly examples and code that is not quite ready to be
: classed as useful

Those three levels make sense -- but they don't map to what's currently
available in the Subversion repository.  Unless I create a new
"useful" directory and make the neccessary changes to the build system to
build everything in it, my current choices are to put new features in
contrib, or add them to the core.

: On Jun 16, 2006, at 6:03 PM, Chris Hostetter wrote:

: > Are there any written (or unwritten) guidelines on when something
: > should
: > be commited to the core code base vs when a contrib module should
: > be used?
: >
: > Obviously if a new feature rquires changing APIs omodifying one of the
: > existing core classes, then that kind of needs to be in the core --
: > and
: > there is precidence for the idea thatlangauge specific analyzers
: > should go
: > in contrib; and then of course there are things like the Span queries
: > which seem like htey would have been a prime canidate for a contrib
: > module
: > but they aren't (possibly just because when they were added there
: > was no
: > "contrib" -- just the sandbox, and it didn't rev with lucene core).
: >
: > ...But I'm just wondering if as we move forward, there should be some
: > sated policy "unless there is a specific reason why it must be in the
: > core, put it in a contrib" to help keep the core small -- or if i'm
: > wrong
: > about hte general sentiment of the Lucene core.
: >
: >
: > (FYI: my impedus for asking this question is LUCENE-406 -- I think
: > it's a
: > pretty handy feature that everyone might want, but that doesn't
: > mean it's
: > not just as usefull commited in contrib/miscellaneous)


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

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

View raw message