lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Hostetter <>
Subject Re: Moving SweetSpotSimilarity out of contrib
Date Thu, 04 Sep 2008 21:59:05 GMT

: Contrib lacks many requirements of core code - it can be java 1.5, it doesn't
: have to be backward compatible, etc. Putting something in core ensures its
: treated as a Lucene first class citizen, stuff in contrib is not held to such
: strict standards.

"Contribs" as an idea lack those requirements -- but that doesn't mean 
individual contribs can't enforce them in order to be "more solid" 
contribs on par with core.

The bottom line is that contribs are about modularization, and 
compartmentilization of features.  We want to be able to build small 
compact jars with well defined dependencies so that if someone wants basic 
indexing plus highlighting they know exactly what jars they need ... they 
don't have to worry about being surprized at run time by a dependency on 
some random class in o.a.l.misc, and they don't have to load every 
Lucene jar (or one monolithic Lucene jar) just to play it safe.

At the end of the day there's no reason not to think of the "core" lucene 
code base as anything other then a contrib which is not allowed to have 
dependencies, and needs to be Java 1.4 compatible.  We could easily 
imagine revamping the Lucene code base something like this...

	mv contrib modules
	mkdir modules/core
	mv src/java modules/core/src
	mv src/test modules/core/test
	mv src/demo modules demo would be a natural migration of what we have now (and it would 
simplify the build process quite a bit).

: Its not that I don't like what you propose, but I don't buy it as very viable
: the way things are now. IMO we would need to do some work to make it a
: reality. It can be said thats the way it is, but my view of things doesnt jive
: with it.

I won't disagree that contribs may seem like second class citizens at the 
moment; I jus think that i would be better to make steps to elevate the 
concept of contribs in peoples minds (by moving more things into 
contribs, solidifying the policies arround individual contribs, 
etc...) then to feed the perception by "promoting" things out of a contrib 
and into the core without any technical reason for doing so (ie: a new 
feature that requires tighter dependency; making SSS the default 
Similarity; etc...)


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

View raw message