lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael McCandless <>
Subject Re: modularization discussion
Date Tue, 03 May 2011 16:55:41 GMT
On the namespace, since Yonik seems concerned about it, and others
aren't (I think?), why don't we leave everything factored out of Solr
under the under org.apache.solr namespace?

Anyone object to that approach?

My only concern is that this sends the message that the module depends
on Solr.... but, this turns into a non-issue once Solr is well
factored into modules, because by the time we arrive at that future,
"depending on Solr" just means "depending on Solr modules", which
resolves my concern!


On Mon, May 2, 2011 at 6:11 PM, Grant Ingersoll <> wrote:
> On Apr 27, 2011, at 11:45 PM, Greg Stein wrote:
>> On Wed, Apr 27, 2011 at 09:25:14AM -0400, Yonik Seeley wrote:
>>> ...
>>> But as I said... it seems only fair to meet half way and use the solr namespace
>>> for some modules and the lucene namespace for others.
>> Please explain this part to me... I really don't understand.
> At the risk of speaking for someone else, I think it has to do w/ wanting to maintain
brand awareness for Solr.  We, as the PMC, currently produce two products:  Apache Lucene
and Apache Solr.  I believe Yonik's concern is that if everything is just labeled Lucene,
then Solr is just seen as a very thin shell around Lucene (which, IMO, would still not be
the case, since wiring together a server app like Solr is non-trivial, but that is my opinion
and I'm not sure if Yonik share's it).  Solr has never been a thin shell around Lucene and
never will be.   However, In some ways, this gets at why I believe Yonik was interested in
a Solr TLP: so that Solr could stand on it's own as a brand and as a first class Apache product
steered by a PMC that is aligned solely w/ producing the Solr (i.e. as a TLP) product as opposed
to the two products we produce now.  (Note, my vote on such a TLP was -1, so please don't
confuse me as arguing for the point, I'm just trying to, hopefully, explain it)
> That being said, 99% of consumers of Solr never even know what is in the underlying namespace
b/c they only ever interact w/ Solr via HTTP (which has solr in the namespace by default)
at the server API level, so at least in my mind, I don't care what the namespace used underneath
is.  Call it lusolr for all I care.
>> What does "fairness" have to do with the codebase?
> I can't speak to this, but perhaps it's just the wrong choice of words and would have
been better said: please don't take this as a reason to gut Solr and call everything Lucene.
>> Isn't the whole
>> point of the Lucene project to create the best code possible, for the
>> benefit of our worldwide users?
> It is.  We do that primarily through the release of two products: Lucene and Solr.  Lucene
is a Java class library.  A good deal of programming is required to create anything meaningful
in terms of a production ready search server.  Solr is a server that takes and makes most
things that are programming tasks in Lucene configuration tasks as well as adds a fair bit
of functionality (distributed search, replication, faceting, auto-suggest, etc.) and is thus
that much easier to put in production (I've seen people be in production on Solr in a matter
of days/weeks, I've never seen that in Lucene)  The crux of this debate is whether these
additional pieces are better served as modules (I think they are) or tightly coupled inside
of Solr (which does have a few benefits from a dev. point of view, even though I firmly believe
they are outweighed by the positives of modularization.)    And, while I think most of us
agree that modularization makes sense, that doesn't mean there aren't reasons against it.
 I also believe we need to take it on a case by case basis.  I also don't think every patch
has to be in it's final place on first commit.  As Otis so often says, it's just software.
 If it doesn't work, change it.  Thus, if people contribute and it lands in Solr, the committer
who commits it need not immediately move it (although, hopefully they will) or ask the contributor
to do so, as that will likely dampen contributions.  Likewise for Lucene.  Along with that,
if and when others wish to refactor, then they should by all means be allowed to do so assuming
of course, all tests across both products still pass.
> In short, I believe people should still contribute where they see they can add the most
value and according to their time schedules.  Additionally, others who have more time or
the ability to refactor for reusability should be free to do so as well.
> I don't know what the outcome of this thread should be, so I guess we need to just move
forward and keep coding away and working to make things better.  Do others see anything broader
here?  A vote?  That would be symbolic, I guess, but doesn't force anyone to do anything
since there isn't a specific issue at hand other than a broad concept that is seen as "good".
> -Grant
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message