Mailing-List: contact dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@lucene.apache.org
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1084)
Subject: Re: modularization discussion
From: Grant Ingersoll <gsingers@apache.org>
In-Reply-To: <BANLkTikk++8ge7hihkUWSkTspiuvg58icA@mail.gmail.com>
Date: Tue, 26 Apr 2011 22:41:41 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <391E344C-C0FA-40DB-B9CD-FA4B13050A13@apache.org>
References: <BANLkTikk++8ge7hihkUWSkTspiuvg58icA@mail.gmail.com>
To: dev@lucene.apache.org


On Apr 26, 2011, at 10:07 PM, Robert Muir wrote:

> Hi,
>=20
> It appears there are some problems with modularization of the code,
> especially between lucene and solr, so I would like for us to have a
> discussion on this thread.
>=20

+1


> The two sides/takes seem to be (with some example reasons):
> 1. pro: for example, modularization can expose features that were
> traditionally in solr to lucene users.

Some other Pros:
Easier to test individual pieces.  Easier to benchmark. =20
More usage =3D=3D more/better features/functionality for everyone. =20
Easier for people to contribute to without having to know the full =
stack. =20
I think most people agree that decoupled, reusable modules are a good =
thing in general as an abstract concept, but, of course, specifics =
matter.

> 2. con: for example, modularization slows development of these
> features and they will evolve slower if they are in lucene.
>=20

I think this needs a bit more explanation.  AIUI, the primary cause for =
concern is that by making something a module, you are taking a private, =
internal API of Solr's and now making it a public API that must be =
maintained (and backwards maintained) which could slow down development =
as one now needs to be concerned with more factors than you would if it =
were merely an implementation detail in Solr.

Other Cons:
The concern was that Solr just becomes an uninteresting, empty shell =
that glues together modules. (I don't agree, but wanted to present what =
I have heard)


> I think we need to somehow get a better understanding of both sides,
> specific examples of portions of the code would be helpful I think.
> Maybe then we can arrive at a compromise so that we aren't so
> frustrated about this issue.
>=20
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>=20


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org