On 3/21/09 1:36 PM, Michael McCandless wrote:
And I don't think the sudden separation of "core" vs "contrib" should
be so prominent (or even visible); it's really a detail of how we
manage source control.
When looking at the website I'd like read that Lucene can do hit
highlighting, powerful query parsing, spell checking, analyze
different languages, etc. I could care less that some of these happen
to live under a "contrib" subdirectory somewhere in the source control
system.
OK, so I think we all agree about the packaging. But I believe it is
also important
how the source code is organized. Maybe Lucene consumers don't care too
much,
however, Lucene is an open source project. So we also want to attract
possible
contributors with a nicely organized code base. If there is a clear
separation between
the different components on a source code level, becoming familiar with
Lucene as a
contributor might not be so overwhelming.
Besides that, I think a one-to-one mapping between the packaging and the
source code
has no disadvantages. (and it would certainly make the build scripts
easier!)
But I think we should still have "main modules", such as core,
queries, analyzers, ... and separately e.g. "sandbox modules?", for
the things currently in contrib that are experimental or, as Mark
called them, "graveyard contribs" :) ... even though we might then
as well ask the questions if we can not really bury the latter
ones...
Could we, instead, adopt some standard way (in the package javadocs)
of stating the maturity/activity/back compat policies/etc of a given
package?
This makes sense; e.g. we could release new modules as beta versions (=
use at own risk,
no backwards-compatibility).
And if we start a new module (e.g. a GSoC project) we could exclude it
from a release
easily if it's truly experimental and not in a release-able state.
So I think the beginnings of a rough proposal is taking shape, for 3.0:
1. Fix web site to give a better intro to Lucene's features, without
exposing core vs. contrib false (to the Lucene consumer)
distinction
2. When releasing, we make a single JAR holding core& contrib
classes for a given area. The final JAR files don't contain a
"core" vs "contrib" distinction.
3. We create a "bundled" JAR that has the common packages
"typically" needed (index/search core, analyzers, queries,
highlighter, spellchecker)
+1 to all three points.
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
