>> 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 index). 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? Mike --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
