Mailing-List: contact java-dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-dev@lucene.apache.org
Received-SPF: pass (athena.apache.org: domain of buschmic@gmail.com designates
 72.14.220.158 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:to:subject:references
         :in-reply-to:content-type;
        b=LML48uK25pMna80eWsgZji+fb/zNzjmD+2jRrXwPwlZu5hsFX76QwHymfcbq6btxm6
         CGxS7VZ49ru4haA9vAVIhyUo0DIJ+hfdnfJQ5S3Edt2M3FT47sOt0Hecy5Co10QlgN6f
         jNxvpDhMl9d8TeXj4w7hFSdSFHzdT4aTLLf1Y=
Message-ID: <49C55E6D.4000208@gmail.com>
Date: Sat, 21 Mar 2009 22:38:53 +0100
From: Michael Busch <buschmic@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US;
 rv:1.9.1b3pre) Gecko/20090223 Thunderbird/3.0b2
MIME-Version: 1.0
To: java-dev@lucene.apache.org
Subject: Re: Modularization
References: <49BEDF79.9010000@gmail.com>
 <49BEE316.5060702@gmail.com>	 <Pine.LNX.4.64.0903201451320.12863@radix.cryptio.net>
	 <49C42657.6050208@gmail.com>
 <49C4B760.5090507@gmail.com>	 <D676484C-C2B3-47C9-9A7F-670D59A0DF6D@mikemccandless.com>
	 <49C4D0C6.9010000@gmail.com>
 <9ac0c6aa0903210536s4d004ed6taa4ba34142536da9@mail.gmail.com>
In-Reply-To: <9ac0c6aa0903210536s4d004ed6taa4ba34142536da9@mail.gmail.com>
Content-Type: multipart/alternative;
 boundary="------------000507020303070605020408"

--------------000507020303070605020408
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
>
>    


--------------000507020303070605020408
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html; charset=ISO-8859-1"
 http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
On 3/21/09 1:36 PM, Michael McCandless wrote:<br>
<blockquote
 cite="mid:9ac0c6aa0903210536s4d004ed6taa4ba34142536da9@mail.gmail.com"
 type="cite">
  <pre wrap="">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.

  </pre>
</blockquote>
OK, so I think we all agree about the packaging. But I believe it is
also important<br>
how the source code is organized. Maybe Lucene consumers don't care too
much, <br>
however, Lucene is an open source project. So we also want to attract
possible<br>
contributors with a nicely organized code base. If there is a clear
separation between <br>
the different components on a source code level, becoming familiar with
Lucene as a <br>
contributor might not be so overwhelming. <br>
<br>
Besides that, I think a one-to-one mapping between the packaging and
the source code<br>
has no disadvantages. (and it would certainly make the build scripts
easier!) <br>
<blockquote
 cite="mid:9ac0c6aa0903210536s4d004ed6taa4ba34142536da9@mail.gmail.com"
 type="cite">
  <pre wrap=""></pre>
  <blockquote type="cite">
    <pre wrap="">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...
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Could we, instead, adopt some standard way (in the package javadocs)
of stating the maturity/activity/back compat policies/etc of a given
package?
  </pre>
</blockquote>
<br>
This makes sense; e.g. we could release new modules as beta versions (=
use at own risk,<br>
no backwards-compatibility).<br>
<br>
And if we start a new module (e.g. a GSoC project) we could exclude it
from a release <br>
easily if it's truly experimental and not in a release-able state.<br>
<blockquote
 cite="mid:9ac0c6aa0903210536s4d004ed6taa4ba34142536da9@mail.gmail.com"
 type="cite">
  <pre wrap="">
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 &amp; 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)

  </pre>
</blockquote>
+1 to all three points.<br>
<br>
<blockquote
 cite="mid:9ac0c6aa0903210536s4d004ed6taa4ba34142536da9@mail.gmail.com"
 type="cite">
  <pre wrap="">Mike

---------------------------------------------------------------------
To unsubscribe, e-mail: <a class="moz-txt-link-abbreviated" href="mailto:java-dev-unsubscribe@lucene.apache.org">java-dev-unsubscribe@lucene.apache.org</a>
For additional commands, e-mail: <a class="moz-txt-link-abbreviated" href="mailto:java-dev-help@lucene.apache.org">java-dev-help@lucene.apache.org</a>


  </pre>
</blockquote>
<br>
</body>
</html>

--------------000507020303070605020408--