: 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
...it 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...)
-Hoss
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
