I think we are mixing up source code modularity with
bundling/packaging.
Honestly, I would not mind much where the source code lives in svn, so
long as a developer, upon downloading Lucene 2.9, can go to *one*
place (javadocs) for Lucene's "queries & filters" and see
{Int,Long}NumberRangeFilter in there.
We are not there today: a developer must first realize there's a whole
separate place to look for "other" queries (contrib/queries). Then
the developer browses that and likely becomes confused/misled by what
TrieRangeQuery means (is it a letter trie?).
My goal here is Lucene's consumability -- when someone new says "hey I
heard about this great search library called Lucene; let me go try it
out" I want that first impression to be as solid as possible. I think
this is very important for growing Lucene's community. This is why
"out of the box" defaults are so crucial (eg changing IW from flushing
every 10 docs to every 16 MB gained sizable throughput).
How many times have we seen a review, article, blog post, etc.,
comparing Lucene to other search libraries only to incorrectly
complain because "Lucene can't do XYZ" or "Lucene's indexing
performance is poor", etc, because they didn't dig in to learn all the
tunings/options/tricks we all know you are supposed to do? (It
frustrates me to end when this happens). This then hurts Lucene's
adoption because others read such articles and conclude Lucene is a
non-starter.
We all ought to be concerned with Lucene's adoption & growth with time
(I am), and first-impression consumability / out of the box defaults
are big drivers of that.
What if (maybe for 3.0, since we can mix in 1.5 sources at that
point?) we change how Lucene is bundled, such that core queries and
contrib/query/* are in one JAR (lucene-query-3.0.jar)? And
lucene-analyzers-3.0.jar would include contrib/analyzers/* and
org/apache/lucene/analysis/*. And lucene-queryparser.jar, etc.
Mike
Michael Busch wrote:
On 3/21/09 12:27 AM, Michael Busch wrote:
+1. I'd love to see Lucene going into such a direction.
However, I'm a little worried about contrib's reputation. I think
it contains components with differing levels of activity, maturity
and support.
So maybe instead of moving things from core into contrib to achieve
the goal you mentioned, we could create a new folder named e.g.
'components', which will contain stuff that we claim is as stable,
mature and supported as the core, just packaged into separate jars.
Those jars should then only have dependencies on the core, but not
on each other. They would also follow the same backwards-
compatibility and other requirements as the core. Thoughts?
I guess something very similar has been proposed and discussed here:
http://www.nabble.com/Moving-SweetSpotSimilarity-out-of-contrib-to19267437.html#a19320894
(same link that Hoss sent while having his deja vu)...
-Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
