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 21:41:32 GMT
>> I think we are considering this for Lucene 3.0 (should be the
>> release after next) which will allow Java 1.5.
> So where are you going to put 1.6 and 1.7 contribs?

This is a good point: core Lucene must remain on "old" JREs, but we
should not force all contrib packages to do so.

> - contrib has always had a lower bar and stuff was committed under
> that lower bar - there should be no blanket promotion.

OK so that was the past, and I agree.

I assume by this you're also advocating that going forward this is an
ongoing reason to put something into contrib?  I agree with that. Ie,
if a contribution is made, but it's not clear the quality is up to
core's standards, I would much rather have some place to commit it
(contrib) than to reject it, because once it has a home here, it has a
chance to gain interest, grow, improve, etc.

But: do you think, for this reason, the web site should continue to
present the dichotomy?

> - contrib items may have different dependencies... putting it all
> under the same source root can make a developers job harder

That's a good point & criterion for leaving something in contrib.

> - many contrib items are less related to lucene-java core indexing
> and searching... if there is no contrib, then they don't belong in
> the lucene-java project at all.

But most contrib packages are very related to Lucene.

Though I agree some contrib packages likely have very narrow
appeal/usage (eg, contrib/db, for using BDB as the raw store for an

And I agree (as above): I would like to have somewhere for
contributions to go, rather than reject them.

> - right now it's clear - core can't have dependencies on non-core
> classes.  If everything is stuck in the same source tree, that goes
> away.

Well... this gets to Hoss's motivation, which I appreciate, to keep
the core tiny.

But that's just good software design and you don't need a divorced
directory structure to achieve that.

> I think there are a lot of benefits to continue considering very
> carefully if something is "core" or not.

I agree, but at least we need some clear criteria so the future
decision process is more straightforward.  Towards that... it seems
like there are good reasons why something should be put into contrib:

  * It uses a version of JDK higher than what core can allow

  * It has external dependencies

  * Its quality is debatable (or at least not proven)

  * It's of somewhat narrow usage/interest (eg: contrib/bdb)

But I don't think "it doesn't have to be in core" (the "software
modularity" goal) is the right reason to put something in contrib.

Getting back to the original topic: Trie(Numeric)RangeFilter runs on
JDK 1.4, has no external dependencies, looks to be high quality, and
likely will have wide appeal.  Doesn't it belong in core?


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

View raw message