Michael Busch <[email protected]> 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.
+1
We want the source code to be well organized: consumability by Lucene
developers (not just Lucene users) is also important for Lucene's
future growth.
> 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!)
Right.
So, towards that... why even break out contrib vs core, in source
control? Can't we simply migrate contrib/* into core, in the right
places?
>> 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).
In fact we already have a 2.9 Jira issue opened to better document the
back-compat/JDK version requirements of all packages.
I think, like we've done with core lately when a new feature is added,
we could have the default assumption be full back compatibility, but
then those classes/methods/packages that are very new and may change
simply say so clearly in their javadocs.
> 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.
Right.
>> 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.
OK.
So I guess I'm proposing adding:
4. Move contrib/* under src/java/*, updating the javadocs to state
back compatibility promises per class/package.
I think net/net this'd be a great simplification?
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
