You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-dev@lucene.apache.org by Yonik Seeley <yo...@apache.org> on 2010/03/16 04:28:46 UTC
lucene and solr trunk
Due to a tremendous amount of work by our newly merged committer
corps, the get-on-lucene-trunk branch (branches/solr) is ready for
prime-time as the new solr trunk! Lucene and Solr need to move to a
common trunk for a host of reasons, including single patches that can
cover both, shared tags and branches, and shared test code w/o a test
jar.
The current Lucene trunk is: .../lucene/java/trunk
The current Solr trunk is: .../lucene/solr/trunk
So, we have a few options on where to put Solr's new trunk:
Lucene moves to Solr's trunk:
/solr/trunk, /solr/trunk/lucene
Solr moves to Lucene's trunk:
/java/trunk, /java/trunk/solr
Both projects move to a new trunk:
/something/trunk/java, /something/trunk/solr
-Yonik
Re: lucene and solr trunk
Posted by Shai Erera <se...@gmail.com>.
Where would the modules live?
I'm not sure if I sent it on this thread or somewhere else, but what about
my proposal to have all three sitting under their own directories, w/ their
own trunk/branch/tags, and if it's easier for dev then put all three under
one root (for permission management maybe)?
Shai
On Tue, Mar 16, 2010 at 11:53 PM, Yonik Seeley <yo...@apache.org> wrote:
> On Tue, Mar 16, 2010 at 5:42 PM, Jake Mannix <ja...@gmail.com>
> wrote:
> > On Tue, Mar 16, 2010 at 2:31 PM, Michael McCandless
> > <lu...@mikemccandless.com> wrote:
> >>
> >> If we move lucene under Solr's existing svn path, ie:
> >>
> >> /solr/trunk/lucene
> >
> > Chiming in just a bit here - isn't there any concern that independent of
> > whether or not people "can"
> > build lucene without checking out solr, the mere fact that Lucene will be
> > effectively a "subdirectory"
> > of solr... is there no concern that there will then be a perception that
> Lucene is a subproject of
> > Solr, instead of vice-versa?
>
> Who would have this perception?
> Casual users will be using downloads.
>
> Likewise, should solr be concerned that it's currently under a lucene
> URL? How many casual users actually understand the difference between
> the lucene TLP and the lucene java subproject?
>
> This is really about what makes most sense for development.
>
> -Yonik
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
>
Re: lucene and solr trunk
Posted by Michael McCandless <lu...@mikemccandless.com>.
Dev is now merged with Solr and Lucene -- that has already passed. If
that will scare customers away, that's a risk we take -- the benefits
of merged dev outweigh that, in my opinion.
The incremental risk that the details of our svn URLs will scare
people away seems negligible.
And we can always change this up, later, if we decide to.
I think what's important now is a we pick something to un-block trunk
dev. Sure people can keep working on the branch but I think it'd be
better if we get this simple "svn move" done so that we can get normal
dev going on a shared trunk again.
Mike
On Tue, Mar 16, 2010 at 5:28 PM, Jake Mannix <ja...@gmail.com> wrote:
>
> On Tue, Mar 16, 2010 at 3:10 PM, Yonik Seeley <ys...@gmail.com> wrote:
>>
>> On Tue, Mar 16, 2010 at 6:01 PM, Jake Mannix <ja...@gmail.com>
>> wrote:
>> > I'm not concerned with casual downloaders. I'm talking
>>
>> > about the companies and people who may or may not be
>>
>> > interested in making multi-million dollar decisions regarding
>>
>> > using or not using Lucene or Solr.
>>
>> Heh - multi-million dollar decisions after a quick glance at an SVN url?
>
> Clearly not. But just as I think that making the development of
> both solr and lucene easier is a noble goal, I think that giving
> people the impression that by choosing to "go with Lucene"
> *means* they "go with Solr" as their end solution is not what
> we want to do. There are some places where Solr is just not
> appropriate but Lucene may be.
> Will this impression be "caused" by a SVN directory url
> alone? Of course not. Merging committer lists, locked
> releases, *and* a SVN url which shows this? Yes, I
> think the kinds of VPs and CTO's I've talked to and
> tried to help decide whether to go with an open-source
> search solution could indeed start to get the feeling that
> there's really just one apache solution, the
> "Solr/Lucene solution". And if they look into Solr and
> decide that this particular application is not for them,
> they may then not look deep enough to see whether
> doing a custom Lucene application *would be*.
> -jake
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: lucene and solr trunk
Posted by Jake Mannix <ja...@gmail.com>.
On Tue, Mar 16, 2010 at 3:10 PM, Yonik Seeley <ys...@gmail.com> wrote:
> On Tue, Mar 16, 2010 at 6:01 PM, Jake Mannix <ja...@gmail.com>
> wrote:
> > I'm not concerned with casual downloaders. I'm talking
>
> about the companies and people who may or may not be
>
> interested in making multi-million dollar decisions regarding
>
> using or not using Lucene or Solr.
>
> Heh - multi-million dollar decisions after a quick glance at an SVN url?
>
Clearly not. But just as I think that making the development of
both solr and lucene easier is a noble goal, I think that giving
people the impression that by choosing to "go with Lucene"
*means* they "go with Solr" as their end solution is not what
we want to do. There are some places where Solr is just not
appropriate but Lucene may be.
Will this impression be "caused" by a SVN directory url
alone? Of course not. Merging committer lists, locked
releases, *and* a SVN url which shows this? Yes, I
think the kinds of VPs and CTO's I've talked to and
tried to help decide whether to go with an open-source
search solution could indeed start to get the feeling that
there's really just one apache solution, the
"Solr/Lucene solution". And if they look into Solr and
decide that this particular application is not for them,
they may then not look deep enough to see whether
doing a custom Lucene application *would be*.
-jake
Re: lucene and solr trunk
Posted by Yonik Seeley <ys...@gmail.com>.
On Tue, Mar 16, 2010 at 6:01 PM, Jake Mannix <ja...@gmail.com> wrote:
> I'm not concerned with casual downloaders. I'm talking about the companies
> and people who
> may or may not be interested in making multi-million dollar decisions
> regarding using or
> not using Lucene or Solr.
Heh - multi-million dollar decisions after a quick glance at an SVN url?
-Yonik
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: lucene and solr trunk
Posted by Michael Busch <bu...@gmail.com>.
What about tagging and branching? When we cut a Lucene release we also
tag Solr, even though it's not being released?
Michael
On 3/16/10 3:47 PM, Michael McCandless wrote:
> But it's actually the reverse? Solr depends on Lucene but not vice/versa.
>
> (If instead I proposed making Solr a subdir of Lucene then I'd agree....)
>
> So... if you checkout only lucene, you can cd there and do all you do
> today with Lucene ("ant test", "ant dist", "svn diff", etc.).
>
> If you checkout solr, you can cd there and "ant test" will run all of
> Lucene's and all of Solr's tests. "svn diff" will include any changes
> to lucene and to solr.
>
> Ie this achieves want we want -- Solr to depend on Lucene but not vice
> versa, right?
>
> Mike
>
> On Tue, Mar 16, 2010 at 5:18 PM, Shai Erera<se...@gmail.com> wrote:
>
>> I have to agree w/ Jake that putting Lucene under Solr gives the impression
>> as if suddenly Lucene became dependent on it ... and for really no good
>> reasons. Are we making that decision to simplify the build of Solr? What are
>> the problems Solr faces today w.r.t. its build and using a Lucene release or
>> trunk revision?
>>
>> I didn't follow the Lucene/Solr merge on general@, because I didn't even
>> know such a beast exists. So I guess I'm missing something ...
>>
>> Shai
>>
>> On Wed, Mar 17, 2010 at 12:01 AM, Jake Mannix<ja...@gmail.com> wrote:
>>
>>> On Tue, Mar 16, 2010 at 2:53 PM, Yonik Seeley<yo...@apache.org> wrote:
>>>
>>>>
>>>>> Chiming in just a bit here - isn't there any concern that independent
>>>>> of
>>>>> whether or not people "can"
>>>>> build lucene without checking out solr, the mere fact that Lucene will
>>>>> be
>>>>> effectively a "subdirectory"
>>>>> of solr... is there no concern that there will then be a perception
>>>>> that Lucene is a subproject of
>>>>> Solr, instead of vice-versa?
>>>>>
>>>> Who would have this perception?
>>>> Casual users will be using downloads.
>>>>
>>> Developers and dev managers at companies doing build vs. buy decisions
>>> regarding
>>> whether they will do one of the following:
>>> 1) pay big bucks to get FAST or whatever
>>> 2) use Solr (free/cheap!)
>>> 3) pay [variable] bucks to build their own with Lucene
>>> 4) pay [variable but high] to build their own from scratch
>>> I'm not concerned with casual downloaders. I'm talking about the
>>> companies and people who
>>> may or may not be interested in making multi-million dollar decisions
>>> regarding using or
>>> not using Lucene or Solr.
>>> -jake
>>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: lucene and solr trunk
Posted by Earwin Burrfoot <ea...@gmail.com>.
> Unless maven has some features i'm not aware of, your "nicely depends"
> works buy pulling Lucene jars from a repository
The 'missing feature' is called multi-module projects.
On Thu, Mar 18, 2010 at 03:33, Chris Hostetter <ho...@fucit.org> wrote:
> : build and nicely gets all dependencies to Lucene and Tika whenever I build
> : or release, no problem there and certainly no need to have it merged into
> : Lucene's svn!
>
> The key distinction is that Solr is allready in "Lucene's svn" -- The
> question is how reorg things in a way that makes it easier to build Solr
> and Lucene-Java all at once, while wtill making it easy to build just
> Lucene-Java.
>
> : Professionally i work on a (world-class) geocoder that also nicely depends
> : on Lucene by using maven, no problems there at all and no need to merge
> : that code in Lucene's svn!
>
> Unless maven has some features i'm not aware of, your "nicely depends"
> works buy pulling Lucene jars from a repository -- changing Solr to do
> that (instead of having committed jars) would be farrly simple (with or
> w/o maven), but that's not the goal. The goal is to make it easy to build
> both at once, have patches that update both, and (make it easy to) have
> atomic svn commits that touch both.
>
>
> -Hoss
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
>
--
Kirill Zakharenko/Кирилл Захаренко (earwin@gmail.com)
Home / Mobile: +7 (495) 683-567-4 / +7 (903) 5-888-423
ICQ: 104465785
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: lucene and solr trunk
Posted by Ian Holsman <li...@holsman.net>.
what other libraries do is have a 'core' or a 'common' bit.. which is
what the lucene library really is.
looking at http://svn.apache.org/repos/asf/lucene/ today I see that
nearly, but it's called 'java'.
maybe just renaming 'java' to 'core' or 'common' (hadoop uses common)
might make sense
and let ivy or maven be responsible for pulling the other parts.
as a weekend developer, I would just pull the bit I care about, and let
ivy or maven get the other bits for me.
btw.. having a master 'pom.xml' in
http://svn.apache.org/repos/asf/lucene/ could just include the the
module pom's and build them
without having to have nightly jars etc.
as for the goal of doing single commits, I've noticed that most of the
discussion has been in the format of
/lucene/XYZ/trunk/...
and /lucene/ABC/trunk
if this is one code base, would it make sense to have it:
/lucene/trunk/ABC
/lucene/trunk/XYZ
?
On 3/18/10 11:33 AM, Chris Hostetter wrote:
> : build and nicely gets all dependencies to Lucene and Tika whenever I build
> : or release, no problem there and certainly no need to have it merged into
> : Lucene's svn!
>
> The key distinction is that Solr is allready in "Lucene's svn" -- The
> question is how reorg things in a way that makes it easier to build Solr
> and Lucene-Java all at once, while wtill making it easy to build just
> Lucene-Java.
>
> : Professionally i work on a (world-class) geocoder that also nicely depends
> : on Lucene by using maven, no problems there at all and no need to merge
> : that code in Lucene's svn!
>
> Unless maven has some features i'm not aware of, your "nicely depends"
> works buy pulling Lucene jars from a repository -- changing Solr to do
> that (instead of having committed jars) would be farrly simple (with or
> w/o maven), but that's not the goal. The goal is to make it easy to build
> both at once, have patches that update both, and (make it easy to) have
> atomic svn commits that touch both.
>
>
> -Hoss
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
>
>
Re: lucene and solr trunk
Posted by Chris Hostetter <ho...@fucit.org>.
: build and nicely gets all dependencies to Lucene and Tika whenever I build
: or release, no problem there and certainly no need to have it merged into
: Lucene's svn!
The key distinction is that Solr is allready in "Lucene's svn" -- The
question is how reorg things in a way that makes it easier to build Solr
and Lucene-Java all at once, while wtill making it easy to build just
Lucene-Java.
: Professionally i work on a (world-class) geocoder that also nicely depends
: on Lucene by using maven, no problems there at all and no need to merge
: that code in Lucene's svn!
Unless maven has some features i'm not aware of, your "nicely depends"
works buy pulling Lucene jars from a repository -- changing Solr to do
that (instead of having committed jars) would be farrly simple (with or
w/o maven), but that's not the goal. The goal is to make it easy to build
both at once, have patches that update both, and (make it easy to) have
atomic svn commits that touch both.
-Hoss
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: lucene and solr trunk
Posted by Earwin Burrfoot <ea...@gmail.com>.
Some of these people got traumatized by maven, now they only can think
in terms of "mash everything together and sprinkle with
hand-downloaded dependency jars".
No offence : )
I, personally, prefer side-by-side layouts. You can add new stuff, and
wire dependencies to the old one, without reorganizing the tree. You
can checkout everything, or just the subset you need.
There is also another way - separate trunks for the modules, so they
can be release-managed separately, but there is a toplevel directory
that svn:external's all these trunks and allows checking
out/building/testing everything at once.
On Wed, Mar 17, 2010 at 11:51, Wouter Heijke <wh...@xs4all.nl> wrote:
> I'm just a surprised observer that doesn't seems to get all the trouble
> and need for this svn merge.
>
> I have my own private Solr-like framework around Lucene. It uses maven to
> build and nicely gets all dependencies to Lucene and Tika whenever I build
> or release, no problem there and certainly no need to have it merged into
> Lucene's svn!
>
> Professionally i work on a (world-class) geocoder that also nicely depends
> on Lucene by using maven, no problems there at all and no need to merge
> that code in Lucene's svn!
>
> Wouter
>
>> But it's actually the reverse? Solr depends on Lucene but not vice/versa.
>>
>> (If instead I proposed making Solr a subdir of Lucene then I'd agree....)
>>
>> So... if you checkout only lucene, you can cd there and do all you do
>> today with Lucene ("ant test", "ant dist", "svn diff", etc.).
>>
>> If you checkout solr, you can cd there and "ant test" will run all of
>> Lucene's and all of Solr's tests. "svn diff" will include any changes
>> to lucene and to solr.
>>
>> Ie this achieves want we want -- Solr to depend on Lucene but not vice
>> versa, right?
>>
>> Mike
>>
>> On Tue, Mar 16, 2010 at 5:18 PM, Shai Erera <se...@gmail.com> wrote:
>>> I have to agree w/ Jake that putting Lucene under Solr gives the
>>> impression
>>> as if suddenly Lucene became dependent on it ... and for really no good
>>> reasons. Are we making that decision to simplify the build of Solr? What
>>> are
>>> the problems Solr faces today w.r.t. its build and using a Lucene
>>> release or
>>> trunk revision?
>>>
>>> I didn't follow the Lucene/Solr merge on general@, because I didn't even
>>> know such a beast exists. So I guess I'm missing something ...
>>>
>>> Shai
>>>
>>> On Wed, Mar 17, 2010 at 12:01 AM, Jake Mannix <ja...@gmail.com>
>>> wrote:
>>>>
>>>> On Tue, Mar 16, 2010 at 2:53 PM, Yonik Seeley <yo...@apache.org> wrote:
>>>>>
>>>>> > Chiming in just a bit here - isn't there any concern that
>>>>> independent
>>>>> > of
>>>>> > whether or not people "can"
>>>>> > build lucene without checking out solr, the mere fact that Lucene
>>>>> will
>>>>> > be
>>>>> > effectively a "subdirectory"
>>>>> > of solr... is there no concern that there will then be a perception
>>>>> > that Lucene is a subproject of
>>>>> > Solr, instead of vice-versa?
>>>>>
>>>>> Who would have this perception?
>>>>> Casual users will be using downloads.
>>>>
>>>> Developers and dev managers at companies doing build vs. buy decisions
>>>> regarding
>>>> whether they will do one of the following:
>>>> 1) pay big bucks to get FAST or whatever
>>>> 2) use Solr (free/cheap!)
>>>> 3) pay [variable] bucks to build their own with Lucene
>>>> 4) pay [variable but high] to build their own from scratch
>>>> I'm not concerned with casual downloaders. I'm talking about the
>>>> companies and people who
>>>> may or may not be interested in making multi-million dollar decisions
>>>> regarding using or
>>>> not using Lucene or Solr.
>>>> -jake
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: java-dev-help@lucene.apache.org
>>
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
>
--
Kirill Zakharenko/Кирилл Захаренко (earwin@gmail.com)
Home / Mobile: +7 (495) 683-567-4 / +7 (903) 5-888-423
ICQ: 104465785
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: lucene and solr trunk
Posted by Wouter Heijke <wh...@xs4all.nl>.
I'm just a surprised observer that doesn't seems to get all the trouble
and need for this svn merge.
I have my own private Solr-like framework around Lucene. It uses maven to
build and nicely gets all dependencies to Lucene and Tika whenever I build
or release, no problem there and certainly no need to have it merged into
Lucene's svn!
Professionally i work on a (world-class) geocoder that also nicely depends
on Lucene by using maven, no problems there at all and no need to merge
that code in Lucene's svn!
Wouter
> But it's actually the reverse? Solr depends on Lucene but not vice/versa.
>
> (If instead I proposed making Solr a subdir of Lucene then I'd agree....)
>
> So... if you checkout only lucene, you can cd there and do all you do
> today with Lucene ("ant test", "ant dist", "svn diff", etc.).
>
> If you checkout solr, you can cd there and "ant test" will run all of
> Lucene's and all of Solr's tests. "svn diff" will include any changes
> to lucene and to solr.
>
> Ie this achieves want we want -- Solr to depend on Lucene but not vice
> versa, right?
>
> Mike
>
> On Tue, Mar 16, 2010 at 5:18 PM, Shai Erera <se...@gmail.com> wrote:
>> I have to agree w/ Jake that putting Lucene under Solr gives the
>> impression
>> as if suddenly Lucene became dependent on it ... and for really no good
>> reasons. Are we making that decision to simplify the build of Solr? What
>> are
>> the problems Solr faces today w.r.t. its build and using a Lucene
>> release or
>> trunk revision?
>>
>> I didn't follow the Lucene/Solr merge on general@, because I didn't even
>> know such a beast exists. So I guess I'm missing something ...
>>
>> Shai
>>
>> On Wed, Mar 17, 2010 at 12:01 AM, Jake Mannix <ja...@gmail.com>
>> wrote:
>>>
>>> On Tue, Mar 16, 2010 at 2:53 PM, Yonik Seeley <yo...@apache.org> wrote:
>>>>
>>>> > Chiming in just a bit here - isn't there any concern that
>>>> independent
>>>> > of
>>>> > whether or not people "can"
>>>> > build lucene without checking out solr, the mere fact that Lucene
>>>> will
>>>> > be
>>>> > effectively a "subdirectory"
>>>> > of solr... is there no concern that there will then be a perception
>>>> > that Lucene is a subproject of
>>>> > Solr, instead of vice-versa?
>>>>
>>>> Who would have this perception?
>>>> Casual users will be using downloads.
>>>
>>> Developers and dev managers at companies doing build vs. buy decisions
>>> regarding
>>> whether they will do one of the following:
>>> 1) pay big bucks to get FAST or whatever
>>> 2) use Solr (free/cheap!)
>>> 3) pay [variable] bucks to build their own with Lucene
>>> 4) pay [variable but high] to build their own from scratch
>>> I'm not concerned with casual downloaders. I'm talking about the
>>> companies and people who
>>> may or may not be interested in making multi-million dollar decisions
>>> regarding using or
>>> not using Lucene or Solr.
>>> -jake
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: lucene and solr trunk
Posted by Michael McCandless <lu...@mikemccandless.com>.
Duh -- I meant to reply to Hoss' proposal, below:
On Tue, Mar 16, 2010 at 5:55 PM, Michael McCandless
<lu...@mikemccandless.com> wrote:
> +1
>
> I like this proposal!
>
> I agree we should not preclude the future (modules), let's just not
> hold up dev today until we solve it.
>
> I agree your side by side solution would allow for us to later factor
> up modules (eg analyzers).
>
> Mike
>
> On Tue, Mar 16, 2010 at 5:47 PM, Michael McCandless
> <lu...@mikemccandless.com> wrote:
>> But it's actually the reverse? Solr depends on Lucene but not vice/versa.
>>
>> (If instead I proposed making Solr a subdir of Lucene then I'd agree....)
>>
>> So... if you checkout only lucene, you can cd there and do all you do
>> today with Lucene ("ant test", "ant dist", "svn diff", etc.).
>>
>> If you checkout solr, you can cd there and "ant test" will run all of
>> Lucene's and all of Solr's tests. "svn diff" will include any changes
>> to lucene and to solr.
>>
>> Ie this achieves want we want -- Solr to depend on Lucene but not vice
>> versa, right?
>>
>> Mike
>>
>> On Tue, Mar 16, 2010 at 5:18 PM, Shai Erera <se...@gmail.com> wrote:
>>> I have to agree w/ Jake that putting Lucene under Solr gives the impression
>>> as if suddenly Lucene became dependent on it ... and for really no good
>>> reasons. Are we making that decision to simplify the build of Solr? What are
>>> the problems Solr faces today w.r.t. its build and using a Lucene release or
>>> trunk revision?
>>>
>>> I didn't follow the Lucene/Solr merge on general@, because I didn't even
>>> know such a beast exists. So I guess I'm missing something ...
>>>
>>> Shai
>>>
>>> On Wed, Mar 17, 2010 at 12:01 AM, Jake Mannix <ja...@gmail.com> wrote:
>>>>
>>>> On Tue, Mar 16, 2010 at 2:53 PM, Yonik Seeley <yo...@apache.org> wrote:
>>>>>
>>>>> > Chiming in just a bit here - isn't there any concern that independent
>>>>> > of
>>>>> > whether or not people "can"
>>>>> > build lucene without checking out solr, the mere fact that Lucene will
>>>>> > be
>>>>> > effectively a "subdirectory"
>>>>> > of solr... is there no concern that there will then be a perception
>>>>> > that Lucene is a subproject of
>>>>> > Solr, instead of vice-versa?
>>>>>
>>>>> Who would have this perception?
>>>>> Casual users will be using downloads.
>>>>
>>>> Developers and dev managers at companies doing build vs. buy decisions
>>>> regarding
>>>> whether they will do one of the following:
>>>> 1) pay big bucks to get FAST or whatever
>>>> 2) use Solr (free/cheap!)
>>>> 3) pay [variable] bucks to build their own with Lucene
>>>> 4) pay [variable but high] to build their own from scratch
>>>> I'm not concerned with casual downloaders. I'm talking about the
>>>> companies and people who
>>>> may or may not be interested in making multi-million dollar decisions
>>>> regarding using or
>>>> not using Lucene or Solr.
>>>> -jake
>>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: lucene and solr trunk
Posted by Michael McCandless <lu...@mikemccandless.com>.
+1
I like this proposal!
I agree we should not preclude the future (modules), let's just not
hold up dev today until we solve it.
I agree your side by side solution would allow for us to later factor
up modules (eg analyzers).
Mike
On Tue, Mar 16, 2010 at 5:47 PM, Michael McCandless
<lu...@mikemccandless.com> wrote:
> But it's actually the reverse? Solr depends on Lucene but not vice/versa.
>
> (If instead I proposed making Solr a subdir of Lucene then I'd agree....)
>
> So... if you checkout only lucene, you can cd there and do all you do
> today with Lucene ("ant test", "ant dist", "svn diff", etc.).
>
> If you checkout solr, you can cd there and "ant test" will run all of
> Lucene's and all of Solr's tests. "svn diff" will include any changes
> to lucene and to solr.
>
> Ie this achieves want we want -- Solr to depend on Lucene but not vice
> versa, right?
>
> Mike
>
> On Tue, Mar 16, 2010 at 5:18 PM, Shai Erera <se...@gmail.com> wrote:
>> I have to agree w/ Jake that putting Lucene under Solr gives the impression
>> as if suddenly Lucene became dependent on it ... and for really no good
>> reasons. Are we making that decision to simplify the build of Solr? What are
>> the problems Solr faces today w.r.t. its build and using a Lucene release or
>> trunk revision?
>>
>> I didn't follow the Lucene/Solr merge on general@, because I didn't even
>> know such a beast exists. So I guess I'm missing something ...
>>
>> Shai
>>
>> On Wed, Mar 17, 2010 at 12:01 AM, Jake Mannix <ja...@gmail.com> wrote:
>>>
>>> On Tue, Mar 16, 2010 at 2:53 PM, Yonik Seeley <yo...@apache.org> wrote:
>>>>
>>>> > Chiming in just a bit here - isn't there any concern that independent
>>>> > of
>>>> > whether or not people "can"
>>>> > build lucene without checking out solr, the mere fact that Lucene will
>>>> > be
>>>> > effectively a "subdirectory"
>>>> > of solr... is there no concern that there will then be a perception
>>>> > that Lucene is a subproject of
>>>> > Solr, instead of vice-versa?
>>>>
>>>> Who would have this perception?
>>>> Casual users will be using downloads.
>>>
>>> Developers and dev managers at companies doing build vs. buy decisions
>>> regarding
>>> whether they will do one of the following:
>>> 1) pay big bucks to get FAST or whatever
>>> 2) use Solr (free/cheap!)
>>> 3) pay [variable] bucks to build their own with Lucene
>>> 4) pay [variable but high] to build their own from scratch
>>> I'm not concerned with casual downloaders. I'm talking about the
>>> companies and people who
>>> may or may not be interested in making multi-million dollar decisions
>>> regarding using or
>>> not using Lucene or Solr.
>>> -jake
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: lucene and solr trunk
Posted by Michael McCandless <lu...@mikemccandless.com>.
But it's actually the reverse? Solr depends on Lucene but not vice/versa.
(If instead I proposed making Solr a subdir of Lucene then I'd agree....)
So... if you checkout only lucene, you can cd there and do all you do
today with Lucene ("ant test", "ant dist", "svn diff", etc.).
If you checkout solr, you can cd there and "ant test" will run all of
Lucene's and all of Solr's tests. "svn diff" will include any changes
to lucene and to solr.
Ie this achieves want we want -- Solr to depend on Lucene but not vice
versa, right?
Mike
On Tue, Mar 16, 2010 at 5:18 PM, Shai Erera <se...@gmail.com> wrote:
> I have to agree w/ Jake that putting Lucene under Solr gives the impression
> as if suddenly Lucene became dependent on it ... and for really no good
> reasons. Are we making that decision to simplify the build of Solr? What are
> the problems Solr faces today w.r.t. its build and using a Lucene release or
> trunk revision?
>
> I didn't follow the Lucene/Solr merge on general@, because I didn't even
> know such a beast exists. So I guess I'm missing something ...
>
> Shai
>
> On Wed, Mar 17, 2010 at 12:01 AM, Jake Mannix <ja...@gmail.com> wrote:
>>
>> On Tue, Mar 16, 2010 at 2:53 PM, Yonik Seeley <yo...@apache.org> wrote:
>>>
>>> > Chiming in just a bit here - isn't there any concern that independent
>>> > of
>>> > whether or not people "can"
>>> > build lucene without checking out solr, the mere fact that Lucene will
>>> > be
>>> > effectively a "subdirectory"
>>> > of solr... is there no concern that there will then be a perception
>>> > that Lucene is a subproject of
>>> > Solr, instead of vice-versa?
>>>
>>> Who would have this perception?
>>> Casual users will be using downloads.
>>
>> Developers and dev managers at companies doing build vs. buy decisions
>> regarding
>> whether they will do one of the following:
>> 1) pay big bucks to get FAST or whatever
>> 2) use Solr (free/cheap!)
>> 3) pay [variable] bucks to build their own with Lucene
>> 4) pay [variable but high] to build their own from scratch
>> I'm not concerned with casual downloaders. I'm talking about the
>> companies and people who
>> may or may not be interested in making multi-million dollar decisions
>> regarding using or
>> not using Lucene or Solr.
>> -jake
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: lucene and solr trunk
Posted by Shai Erera <se...@gmail.com>.
I have to agree w/ Jake that putting Lucene under Solr gives the impression
as if suddenly Lucene became dependent on it ... and for really no good
reasons. Are we making that decision to simplify the build of Solr? What are
the problems Solr faces today w.r.t. its build and using a Lucene release or
trunk revision?
I didn't follow the Lucene/Solr merge on general@, because I didn't even
know such a beast exists. So I guess I'm missing something ...
Shai
On Wed, Mar 17, 2010 at 12:01 AM, Jake Mannix <ja...@gmail.com> wrote:
> On Tue, Mar 16, 2010 at 2:53 PM, Yonik Seeley <yo...@apache.org> wrote:
>>
>> > Chiming in just a bit here - isn't there any concern that independent
>> of
>> > whether or not people "can"
>> > build lucene without checking out solr, the mere fact that Lucene will
>> be
>> > effectively a "subdirectory"
>> > of solr... is there no concern that there will then be a perception
>> that Lucene is a subproject of
>> > Solr, instead of vice-versa?
>>
>> Who would have this perception?
>> Casual users will be using downloads.
>>
>
> Developers and dev managers at companies doing build vs. buy decisions
> regarding
> whether they will do one of the following:
>
> 1) pay big bucks to get FAST or whatever
> 2) use Solr (free/cheap!)
> 3) pay [variable] bucks to build their own with Lucene
> 4) pay [variable but high] to build their own from scratch
>
> I'm not concerned with casual downloaders. I'm talking about the companies
> and people who
> may or may not be interested in making multi-million dollar decisions
> regarding using or
> not using Lucene or Solr.
>
> -jake
>
Re: lucene and solr trunk
Posted by Jake Mannix <ja...@gmail.com>.
On Tue, Mar 16, 2010 at 2:53 PM, Yonik Seeley <yo...@apache.org> wrote:
>
> > Chiming in just a bit here - isn't there any concern that independent of
> > whether or not people "can"
> > build lucene without checking out solr, the mere fact that Lucene will be
> > effectively a "subdirectory"
> > of solr... is there no concern that there will then be a perception that
> Lucene is a subproject of
> > Solr, instead of vice-versa?
>
> Who would have this perception?
> Casual users will be using downloads.
>
Developers and dev managers at companies doing build vs. buy decisions
regarding
whether they will do one of the following:
1) pay big bucks to get FAST or whatever
2) use Solr (free/cheap!)
3) pay [variable] bucks to build their own with Lucene
4) pay [variable but high] to build their own from scratch
I'm not concerned with casual downloaders. I'm talking about the companies
and people who
may or may not be interested in making multi-million dollar decisions
regarding using or
not using Lucene or Solr.
-jake
Re: lucene and solr trunk
Posted by Yonik Seeley <yo...@apache.org>.
On Tue, Mar 16, 2010 at 5:42 PM, Jake Mannix <ja...@gmail.com> wrote:
> On Tue, Mar 16, 2010 at 2:31 PM, Michael McCandless
> <lu...@mikemccandless.com> wrote:
>>
>> If we move lucene under Solr's existing svn path, ie:
>>
>> /solr/trunk/lucene
>
> Chiming in just a bit here - isn't there any concern that independent of
> whether or not people "can"
> build lucene without checking out solr, the mere fact that Lucene will be
> effectively a "subdirectory"
> of solr... is there no concern that there will then be a perception that Lucene is a subproject of
> Solr, instead of vice-versa?
Who would have this perception?
Casual users will be using downloads.
Likewise, should solr be concerned that it's currently under a lucene
URL? How many casual users actually understand the difference between
the lucene TLP and the lucene java subproject?
This is really about what makes most sense for development.
-Yonik
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: lucene and solr trunk
Posted by Jake Mannix <ja...@gmail.com>.
On Tue, Mar 16, 2010 at 2:31 PM, Michael McCandless <
lucene@mikemccandless.com> wrote:
>
> If we move lucene under Solr's existing svn path, ie:
>
> /solr/trunk/lucene
Chiming in just a bit here - isn't there any concern that independent of
whether or not people "can"
build lucene without checking out solr, the mere fact that Lucene will be
effectively a "subdirectory"
of solr... is there no concern that there will then be a perception that
Lucene is a subproject of
Solr, instead of vice-versa?
The way mavenified projects work is that there would instead be a top level
in which both solr
and lucene would be submodules (and thus also subdirectories in svn), with a
dependency
from solr to lucene (in the pom.xml for maven, but easy enough to do with
the build.xml with
ant). Checking out solr without lucene should be doable (using snapshot
jars from lucene
trunk nightly, maybe?), and the reverse should be easy, as could be checking
out the
top-level and getting everything (including a top-level build.xml which
<include>'s or antcall's
into the subdirectory build.xmls).
It seems really weird to have Lucene appear as a subdirectory of Solr,
especially for people
out there who aren't using Solr.
-jake
Re: lucene and solr trunk
Posted by Michael McCandless <lu...@mikemccandless.com>.
The primary concern seems to be ensuring that, once we
merge svn, one can still checkout & build & run tests/etc for
Lucene alone.
If we move lucene under Solr's existing svn path, ie:
/solr/trunk/lucene
and then fixup solr's build files to go and compile sources from the
lucene dir, run tests there, etc., then, one can still checkout & run
lucene fully independently -- this addresses that concern?
So.... how about we start with this approach? Progress not
perfection... If somehow this layout is a problem then we can just
move things around, again.
Alot of great progress has already been made on the temporary branch
-- Solr runs fine on Lucene trunk! And, also on flex. We need to
settle an initial svn structure so the changes on the branch can
be fully reviewed & then committed to trunk and normal dev can
proceed...
We don't need to solve how modules/contribs, etc., are going to be
fixed, now -- that all can come later. IRC issues, using GIT instead,
etc. should also be discussed separately. Let's just pick a place in
svn and free up ongoing dev...
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: lucene and solr trunk
Posted by Robert Muir <rc...@gmail.com>.
On Mon, Mar 15, 2010 at 11:41 PM, Mark Miller <ma...@gmail.com> wrote:
>>
>> Solr moves to Lucene's trunk:
>> /java/trunk, /java/trunk/sol
>
> +1. With the goal of merged dev, merged tests, this looks the best to me.
> Simple to do patches that span both, simple to setup
> Solr to use Lucene trunk rather than jars. Short paths. Simple. I like it.
>
+1
--
Robert Muir
rcmuir@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: lucene and solr trunk
Posted by Mark Miller <ma...@gmail.com>.
On 03/15/2010 11:28 PM, Yonik Seeley wrote:
> So, we have a few options on where to put Solr's new trunk:
>
>
> Solr moves to Lucene's trunk:
> /java/trunk, /java/trunk/sol
+1. With the goal of merged dev, merged tests, this looks the best to
me. Simple to do patches that span both, simple to setup
Solr to use Lucene trunk rather than jars. Short paths. Simple. I like it.
--
- Mark
http://www.lucidimagination.com
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: lucene and solr trunk
Posted by Marvin Humphrey <ma...@rectangular.com>.
On Tue, Mar 16, 2010 at 02:57:33PM -0700, Otis Gospodnetic wrote:
> Check out the dir structure mentioned here:
> http://markmail.org/message/gwpmaevw7tavqqge
>
> Isn't that what we want?
I think the downside of that hierarchy is that you will need the "modules"
directory if you're working on Lucene, and with Solr under "modules/solr",
you'll have to get all of Solr, too.
If Solr were a thin layer for sharding, I agree that would be a good place for
it... but as things stand, that's gonna be one big "modules" checkout.
Marvin Humphrey
Re: lucene and solr trunk
Posted by Jake Mannix <ja...@gmail.com>.
On Tue, Mar 16, 2010 at 2:57 PM, Otis Gospodnetic <
otis_gospodnetic@yahoo.com> wrote:
> Hi,
>
> Check out the dir structure mentioned here:
> http://markmail.org/message/gwpmaevw7tavqqge
>
> Isn't that what we want?
>
I'm totally down with this structure, personally. Not that I matter. :)
-jake
Re: lucene and solr trunk
Posted by Robert Muir <rc...@gmail.com>.
On Wed, Mar 17, 2010 at 9:09 AM, Michael McCandless
<lu...@mikemccandless.com> wrote:
> Git, Maven, Hg, etc., all sound great for the future, but let's focus
> now on the baby step (how to re-org svn), today, so we can land the
> Solr upgrade work now being done on a branch...
>
I agree.
Another thing anyone can do to help if they have a spare few minutes,
is to review the technical work done in the branch and provide
feedback.
The big JIRA issue is located at
https://issues.apache.org/jira/browse/SOLR-1659 and other issues are
linked to it.
--
Robert Muir
rcmuir@gmail.com
Re: lucene and solr trunk
Posted by Michael McCandless <lu...@mikemccandless.com>.
Git, Maven, Hg, etc., all sound great for the future, but let's focus
now on the baby step (how to re-org svn), today, so we can land the
Solr upgrade work now being done on a branch...
Hoss's side-by-side proposal sounds great... and his concrete steps
"that could be done today" look good (I'm hoping Uwe "the policeman
who wears many hats" volunteers ;).
Mike
On Wed, Mar 17, 2010 at 8:05 AM, Otis Gospodnetic
<ot...@yahoo.com> wrote:
> +1 for this structure and this set of steps.
> Otis
>
>
>
>
> ----- Original Message ----
>> From: Chris Hostetter <ho...@fucit.org>
>> To: solr-dev@lucene.apache.org
>> Sent: Tue, March 16, 2010 6:46:19 PM
>> Subject: Re: lucene and solr trunk
>>
>> : Otis, yes, I think so, eventually. But that's gonna take much more
>> discussion.
> :
> : I don't think this initial cutover should try to "solve"
>> how modules
> : will be organized, yet... we'll get there,
>> eventually.
>
> But we should at least consider it, and not move in a
>> direction that's
> distinct from the ultimate goal of better refactoring
>> (especailly since
> that was one of the main goals of unifying development
>> efforts)
>
> Here's my concrete suggestion that could be done today (for
>> simplicity:
> $svn =
>> target=_blank >https://svn.apache.org/repos/asf/lucene)...
>
> svn
>> mv $svn/java/trunk $svn/java/tmp-migration
> svn mkdir
>> $svn/java/trunk
> svn mv $svn/solr/trunk $svn/java/trunk/solr
>
>> svn mv $svn/java/tmp-migration $svn/java/trunk/core
>
> At which
>> point:
>
> 0. People who want to work only on "Lucene-Java" can start
>> checking out
> $svn/java/trunk/core (i'm pretty sure existing checkouts will
>> continue to
> work w/o any changes, the svn info should just update
>> itself)
>
> 1. build files can be added to (the new) $svn/java/trunk to build
>> ./core
> followed by ./solr
>
> 2. the build files in $svn/java/trunk/solr
>> can be modified to look at
> ../core/ to find lucene jars
>
> 3. people who
>> care about Solr (including all committers) should start
> checking out and
>> building all of $svn/java/trunk
>
> 4. Long term, we could choose to branch
>> all of $svn/java/trunk
> for releases ... AND/OR we could choose to branch
>> specific modules
> (ie: solr) independently (with modifications to the build
>> files on those
> branches to pull in their dependencies from alternate
>> locations
>
> 5. Long term, we can start refactoring additional "modules" out
>> of
> $svn/java/trunk/solr and $svn/java/trunk/core (like
>>
> $svn/java/trunk/core/contrib) into their own directory in
>> $svn/java/trunk
>
> 6. Long term, people who want to work on more then just
>> "core" but don't
> care about certain "modules" (like solr) can do a simple
>> non-recursive
> checkout of $svn/java/trunk and then do full checkouts of
>> whatever modules
> they care about
>
>
> (Please note: I'm just trying to
>> list things we *could* do if we go this
> route, i'm not advocating that we
>> *should* do any of these things)
>
> I can't think of any objections people
>> have raised to any of the previous
> suggestions which apply to this
>> suggestion. Is there anything people can
> think of that would be
>> useful, but not possible, if we go this route?
>
>
> -Hoss
>
Re: lucene and solr trunk
Posted by Otis Gospodnetic <ot...@yahoo.com>.
+1 for this structure and this set of steps.
Otis
----- Original Message ----
> From: Chris Hostetter <ho...@fucit.org>
> To: solr-dev@lucene.apache.org
> Sent: Tue, March 16, 2010 6:46:19 PM
> Subject: Re: lucene and solr trunk
>
> : Otis, yes, I think so, eventually. But that's gonna take much more
> discussion.
:
: I don't think this initial cutover should try to "solve"
> how modules
: will be organized, yet... we'll get there,
> eventually.
But we should at least consider it, and not move in a
> direction that's
distinct from the ultimate goal of better refactoring
> (especailly since
that was one of the main goals of unifying development
> efforts)
Here's my concrete suggestion that could be done today (for
> simplicity:
$svn =
> target=_blank >https://svn.apache.org/repos/asf/lucene)...
svn
> mv $svn/java/trunk $svn/java/tmp-migration
svn mkdir
> $svn/java/trunk
svn mv $svn/solr/trunk $svn/java/trunk/solr
> svn mv $svn/java/tmp-migration $svn/java/trunk/core
At which
> point:
0. People who want to work only on "Lucene-Java" can start
> checking out
$svn/java/trunk/core (i'm pretty sure existing checkouts will
> continue to
work w/o any changes, the svn info should just update
> itself)
1. build files can be added to (the new) $svn/java/trunk to build
> ./core
followed by ./solr
2. the build files in $svn/java/trunk/solr
> can be modified to look at
../core/ to find lucene jars
3. people who
> care about Solr (including all committers) should start
checking out and
> building all of $svn/java/trunk
4. Long term, we could choose to branch
> all of $svn/java/trunk
for releases ... AND/OR we could choose to branch
> specific modules
(ie: solr) independently (with modifications to the build
> files on those
branches to pull in their dependencies from alternate
> locations
5. Long term, we can start refactoring additional "modules" out
> of
$svn/java/trunk/solr and $svn/java/trunk/core (like
>
$svn/java/trunk/core/contrib) into their own directory in
> $svn/java/trunk
6. Long term, people who want to work on more then just
> "core" but don't
care about certain "modules" (like solr) can do a simple
> non-recursive
checkout of $svn/java/trunk and then do full checkouts of
> whatever modules
they care about
(Please note: I'm just trying to
> list things we *could* do if we go this
route, i'm not advocating that we
> *should* do any of these things)
I can't think of any objections people
> have raised to any of the previous
suggestions which apply to this
> suggestion. Is there anything people can
think of that would be
> useful, but not possible, if we go this route?
-Hoss
Re: lucene and solr trunk
Posted by Michael McCandless <lu...@mikemccandless.com>.
All tests pass for me :)
Mike
On Thu, Mar 18, 2010 at 12:27 PM, Mark Miller <ma...@gmail.com> wrote:
> Alight, so we have implemented Hoss' suggestion here on the lucene/solr
> merged dev branch at lucene/solr/branches/newtrunk.
>
> Feel free to check it out and give some feedback.
>
> We also roughly have Solr running on Lucene trunk - eg compiling Solr will
> first compile lucene and run off those compiled class files. Running dist or
> example in Solr will grab Lucene's jars and put them in the war. This still
> needs further love, but it works.
>
> There is also a top level build.xml with two targets: clean, and test. Clean
> will clean both Lucene and Solr, and test will run tests for both Lucene and
> Solr.
>
> Thanks to everyone that contributed to getting all this working!
>
> --
> - Mark
>
> http://www.lucidimagination.com
>
>
>
> On 03/17/2010 12:40 PM, Mark Miller wrote:
>>
>> Okay, so this looks good to me (a few others seemed to like it - though
>> Lucene-Dev was somehow dropped earlier) - lets try this out on the branch?
>> (then we can get rid of that "horrible" branch name ;) )
>>
>> Anyone on the current branch object to having to do a quick svn switch?
>>
>> On 03/16/2010 06:46 PM, Chris Hostetter wrote:
>>>
>>> : Otis, yes, I think so, eventually. But that's gonna take much more
>>> discussion.
>>> :
>>> : I don't think this initial cutover should try to "solve" how modules
>>> : will be organized, yet... we'll get there, eventually.
>>>
>>> But we should at least consider it, and not move in a direction that's
>>> distinct from the ultimate goal of better refactoring (especailly since
>>> that was one of the main goals of unifying development efforts)
>>>
>>> Here's my concrete suggestion that could be done today (for simplicity:
>>> $svn = https://svn.apache.org/repos/asf/lucene)...
>>>
>>> svn mv $svn/java/trunk $svn/java/tmp-migration
>>> svn mkdir $svn/java/trunk
>>> svn mv $svn/solr/trunk $svn/java/trunk/solr
>>> svn mv $svn/java/tmp-migration $svn/java/trunk/core
>>>
>>> At which point:
>>>
>>> 0. People who want to work only on "Lucene-Java" can start checking out
>>> $svn/java/trunk/core (i'm pretty sure existing checkouts will continue to
>>> work w/o any changes, the svn info should just update itself)
>>>
>>> 1. build files can be added to (the new) $svn/java/trunk to build ./core
>>> followed by ./solr
>>>
>>> 2. the build files in $svn/java/trunk/solr can be modified to look at
>>> ../core/ to find lucene jars
>>>
>>> 3. people who care about Solr (including all committers) should start
>>> checking out and building all of $svn/java/trunk
>>>
>>> 4. Long term, we could choose to branch all of $svn/java/trunk
>>> for releases ... AND/OR we could choose to branch specific modules
>>> (ie: solr) independently (with modifications to the build files on those
>>> branches to pull in their dependencies from alternate locations
>>>
>>> 5. Long term, we can start refactoring additional "modules" out of
>>> $svn/java/trunk/solr and $svn/java/trunk/core (like
>>> $svn/java/trunk/core/contrib) into their own directory in $svn/java/trunk
>>>
>>> 6. Long term, people who want to work on more then just "core" but don't
>>> care about certain "modules" (like solr) can do a simple non-recursive
>>> checkout of $svn/java/trunk and then do full checkouts of whatever
>>> modules
>>> they care about
>>>
>>>
>>> (Please note: I'm just trying to list things we *could* do if we go this
>>> route, i'm not advocating that we *should* do any of these things)
>>>
>>> I can't think of any objections people have raised to any of the previous
>>> suggestions which apply to this suggestion. Is there anything people can
>>> think of that would be useful, but not possible, if we go this route?
>>>
>>>
>>> -Hoss
>>>
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: lucene and solr trunk
Posted by Michael McCandless <lu...@mikemccandless.com>.
All tests pass for me :)
Mike
On Thu, Mar 18, 2010 at 12:27 PM, Mark Miller <ma...@gmail.com> wrote:
> Alight, so we have implemented Hoss' suggestion here on the lucene/solr
> merged dev branch at lucene/solr/branches/newtrunk.
>
> Feel free to check it out and give some feedback.
>
> We also roughly have Solr running on Lucene trunk - eg compiling Solr will
> first compile lucene and run off those compiled class files. Running dist or
> example in Solr will grab Lucene's jars and put them in the war. This still
> needs further love, but it works.
>
> There is also a top level build.xml with two targets: clean, and test. Clean
> will clean both Lucene and Solr, and test will run tests for both Lucene and
> Solr.
>
> Thanks to everyone that contributed to getting all this working!
>
> --
> - Mark
>
> http://www.lucidimagination.com
>
>
>
> On 03/17/2010 12:40 PM, Mark Miller wrote:
>>
>> Okay, so this looks good to me (a few others seemed to like it - though
>> Lucene-Dev was somehow dropped earlier) - lets try this out on the branch?
>> (then we can get rid of that "horrible" branch name ;) )
>>
>> Anyone on the current branch object to having to do a quick svn switch?
>>
>> On 03/16/2010 06:46 PM, Chris Hostetter wrote:
>>>
>>> : Otis, yes, I think so, eventually. But that's gonna take much more
>>> discussion.
>>> :
>>> : I don't think this initial cutover should try to "solve" how modules
>>> : will be organized, yet... we'll get there, eventually.
>>>
>>> But we should at least consider it, and not move in a direction that's
>>> distinct from the ultimate goal of better refactoring (especailly since
>>> that was one of the main goals of unifying development efforts)
>>>
>>> Here's my concrete suggestion that could be done today (for simplicity:
>>> $svn = https://svn.apache.org/repos/asf/lucene)...
>>>
>>> svn mv $svn/java/trunk $svn/java/tmp-migration
>>> svn mkdir $svn/java/trunk
>>> svn mv $svn/solr/trunk $svn/java/trunk/solr
>>> svn mv $svn/java/tmp-migration $svn/java/trunk/core
>>>
>>> At which point:
>>>
>>> 0. People who want to work only on "Lucene-Java" can start checking out
>>> $svn/java/trunk/core (i'm pretty sure existing checkouts will continue to
>>> work w/o any changes, the svn info should just update itself)
>>>
>>> 1. build files can be added to (the new) $svn/java/trunk to build ./core
>>> followed by ./solr
>>>
>>> 2. the build files in $svn/java/trunk/solr can be modified to look at
>>> ../core/ to find lucene jars
>>>
>>> 3. people who care about Solr (including all committers) should start
>>> checking out and building all of $svn/java/trunk
>>>
>>> 4. Long term, we could choose to branch all of $svn/java/trunk
>>> for releases ... AND/OR we could choose to branch specific modules
>>> (ie: solr) independently (with modifications to the build files on those
>>> branches to pull in their dependencies from alternate locations
>>>
>>> 5. Long term, we can start refactoring additional "modules" out of
>>> $svn/java/trunk/solr and $svn/java/trunk/core (like
>>> $svn/java/trunk/core/contrib) into their own directory in $svn/java/trunk
>>>
>>> 6. Long term, people who want to work on more then just "core" but don't
>>> care about certain "modules" (like solr) can do a simple non-recursive
>>> checkout of $svn/java/trunk and then do full checkouts of whatever
>>> modules
>>> they care about
>>>
>>>
>>> (Please note: I'm just trying to list things we *could* do if we go this
>>> route, i'm not advocating that we *should* do any of these things)
>>>
>>> I can't think of any objections people have raised to any of the previous
>>> suggestions which apply to this suggestion. Is there anything people can
>>> think of that would be useful, but not possible, if we go this route?
>>>
>>>
>>> -Hoss
>>>
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
>
Re: lucene and solr trunk
Posted by Mark Miller <ma...@gmail.com>.
Alight, so we have implemented Hoss' suggestion here on the lucene/solr
merged dev branch at lucene/solr/branches/newtrunk.
Feel free to check it out and give some feedback.
We also roughly have Solr running on Lucene trunk - eg compiling Solr
will first compile lucene and run off those compiled class files.
Running dist or example in Solr will grab Lucene's jars and put them in
the war. This still needs further love, but it works.
There is also a top level build.xml with two targets: clean, and test.
Clean will clean both Lucene and Solr, and test will run tests for both
Lucene and Solr.
Thanks to everyone that contributed to getting all this working!
--
- Mark
http://www.lucidimagination.com
On 03/17/2010 12:40 PM, Mark Miller wrote:
> Okay, so this looks good to me (a few others seemed to like it -
> though Lucene-Dev was somehow dropped earlier) - lets try this out on
> the branch? (then we can get rid of that "horrible" branch name ;) )
>
> Anyone on the current branch object to having to do a quick svn switch?
>
> On 03/16/2010 06:46 PM, Chris Hostetter wrote:
>> : Otis, yes, I think so, eventually. But that's gonna take much more
>> discussion.
>> :
>> : I don't think this initial cutover should try to "solve" how modules
>> : will be organized, yet... we'll get there, eventually.
>>
>> But we should at least consider it, and not move in a direction that's
>> distinct from the ultimate goal of better refactoring (especailly since
>> that was one of the main goals of unifying development efforts)
>>
>> Here's my concrete suggestion that could be done today (for simplicity:
>> $svn = https://svn.apache.org/repos/asf/lucene)...
>>
>> svn mv $svn/java/trunk $svn/java/tmp-migration
>> svn mkdir $svn/java/trunk
>> svn mv $svn/solr/trunk $svn/java/trunk/solr
>> svn mv $svn/java/tmp-migration $svn/java/trunk/core
>>
>> At which point:
>>
>> 0. People who want to work only on "Lucene-Java" can start checking out
>> $svn/java/trunk/core (i'm pretty sure existing checkouts will
>> continue to
>> work w/o any changes, the svn info should just update itself)
>>
>> 1. build files can be added to (the new) $svn/java/trunk to build ./core
>> followed by ./solr
>>
>> 2. the build files in $svn/java/trunk/solr can be modified to look at
>> ../core/ to find lucene jars
>>
>> 3. people who care about Solr (including all committers) should start
>> checking out and building all of $svn/java/trunk
>>
>> 4. Long term, we could choose to branch all of $svn/java/trunk
>> for releases ... AND/OR we could choose to branch specific modules
>> (ie: solr) independently (with modifications to the build files on those
>> branches to pull in their dependencies from alternate locations
>>
>> 5. Long term, we can start refactoring additional "modules" out of
>> $svn/java/trunk/solr and $svn/java/trunk/core (like
>> $svn/java/trunk/core/contrib) into their own directory in
>> $svn/java/trunk
>>
>> 6. Long term, people who want to work on more then just "core" but don't
>> care about certain "modules" (like solr) can do a simple non-recursive
>> checkout of $svn/java/trunk and then do full checkouts of whatever
>> modules
>> they care about
>>
>>
>> (Please note: I'm just trying to list things we *could* do if we go this
>> route, i'm not advocating that we *should* do any of these things)
>>
>> I can't think of any objections people have raised to any of the
>> previous
>> suggestions which apply to this suggestion. Is there anything people
>> can
>> think of that would be useful, but not possible, if we go this route?
>>
>>
>> -Hoss
>>
>
>
Re: lucene and solr trunk
Posted by Mark Miller <ma...@gmail.com>.
Alight, so we have implemented Hoss' suggestion here on the lucene/solr
merged dev branch at lucene/solr/branches/newtrunk.
Feel free to check it out and give some feedback.
We also roughly have Solr running on Lucene trunk - eg compiling Solr
will first compile lucene and run off those compiled class files.
Running dist or example in Solr will grab Lucene's jars and put them in
the war. This still needs further love, but it works.
There is also a top level build.xml with two targets: clean, and test.
Clean will clean both Lucene and Solr, and test will run tests for both
Lucene and Solr.
Thanks to everyone that contributed to getting all this working!
--
- Mark
http://www.lucidimagination.com
On 03/17/2010 12:40 PM, Mark Miller wrote:
> Okay, so this looks good to me (a few others seemed to like it -
> though Lucene-Dev was somehow dropped earlier) - lets try this out on
> the branch? (then we can get rid of that "horrible" branch name ;) )
>
> Anyone on the current branch object to having to do a quick svn switch?
>
> On 03/16/2010 06:46 PM, Chris Hostetter wrote:
>> : Otis, yes, I think so, eventually. But that's gonna take much more
>> discussion.
>> :
>> : I don't think this initial cutover should try to "solve" how modules
>> : will be organized, yet... we'll get there, eventually.
>>
>> But we should at least consider it, and not move in a direction that's
>> distinct from the ultimate goal of better refactoring (especailly since
>> that was one of the main goals of unifying development efforts)
>>
>> Here's my concrete suggestion that could be done today (for simplicity:
>> $svn = https://svn.apache.org/repos/asf/lucene)...
>>
>> svn mv $svn/java/trunk $svn/java/tmp-migration
>> svn mkdir $svn/java/trunk
>> svn mv $svn/solr/trunk $svn/java/trunk/solr
>> svn mv $svn/java/tmp-migration $svn/java/trunk/core
>>
>> At which point:
>>
>> 0. People who want to work only on "Lucene-Java" can start checking out
>> $svn/java/trunk/core (i'm pretty sure existing checkouts will
>> continue to
>> work w/o any changes, the svn info should just update itself)
>>
>> 1. build files can be added to (the new) $svn/java/trunk to build ./core
>> followed by ./solr
>>
>> 2. the build files in $svn/java/trunk/solr can be modified to look at
>> ../core/ to find lucene jars
>>
>> 3. people who care about Solr (including all committers) should start
>> checking out and building all of $svn/java/trunk
>>
>> 4. Long term, we could choose to branch all of $svn/java/trunk
>> for releases ... AND/OR we could choose to branch specific modules
>> (ie: solr) independently (with modifications to the build files on those
>> branches to pull in their dependencies from alternate locations
>>
>> 5. Long term, we can start refactoring additional "modules" out of
>> $svn/java/trunk/solr and $svn/java/trunk/core (like
>> $svn/java/trunk/core/contrib) into their own directory in
>> $svn/java/trunk
>>
>> 6. Long term, people who want to work on more then just "core" but don't
>> care about certain "modules" (like solr) can do a simple non-recursive
>> checkout of $svn/java/trunk and then do full checkouts of whatever
>> modules
>> they care about
>>
>>
>> (Please note: I'm just trying to list things we *could* do if we go this
>> route, i'm not advocating that we *should* do any of these things)
>>
>> I can't think of any objections people have raised to any of the
>> previous
>> suggestions which apply to this suggestion. Is there anything people
>> can
>> think of that would be useful, but not possible, if we go this route?
>>
>>
>> -Hoss
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: lucene and solr trunk
Posted by Mark Miller <ma...@gmail.com>.
On 03/17/2010 12:46 PM, Robert Muir wrote:
> On Wed, Mar 17, 2010 at 12:40 PM, Mark Miller<ma...@gmail.com> wrote:
>
>> Okay, so this looks good to me (a few others seemed to like it - though
>> Lucene-Dev was somehow dropped earlier) - lets try this out on the branch?
>> (then we can get rid of that "horrible" branch name ;) )
>>
>> Anyone on the current branch object to having to do a quick svn switch?
>>
>>
> +1
>
>
I've moved solr to newtrunk/solr for to experiment with this layout.
--
- Mark
http://www.lucidimagination.com
Re: lucene and solr trunk
Posted by Robert Muir <rc...@gmail.com>.
On Wed, Mar 17, 2010 at 12:40 PM, Mark Miller <ma...@gmail.com> wrote:
> Okay, so this looks good to me (a few others seemed to like it - though
> Lucene-Dev was somehow dropped earlier) - lets try this out on the branch?
> (then we can get rid of that "horrible" branch name ;) )
>
> Anyone on the current branch object to having to do a quick svn switch?
>
+1
--
Robert Muir
rcmuir@gmail.com
Re: lucene and solr trunk
Posted by Chris Hostetter <ho...@fucit.org>.
: Okay, so this looks good to me (a few others seemed to like it - though
: Lucene-Dev was somehow dropped earlier) - lets try this out on the branch?
It's the hassle of cross posting, really easy for someone to not reply to
all (especailly since i think all of the ASF lists rewrite the Reply-To
header, but i haven't double checked that that's what happened in this
instance)
-Hoss
Re: lucene and solr trunk
Posted by Mark Miller <ma...@gmail.com>.
Okay, so this looks good to me (a few others seemed to like it - though
Lucene-Dev was somehow dropped earlier) - lets try this out on the
branch? (then we can get rid of that "horrible" branch name ;) )
Anyone on the current branch object to having to do a quick svn switch?
On 03/16/2010 06:46 PM, Chris Hostetter wrote:
> : Otis, yes, I think so, eventually. But that's gonna take much more discussion.
> :
> : I don't think this initial cutover should try to "solve" how modules
> : will be organized, yet... we'll get there, eventually.
>
> But we should at least consider it, and not move in a direction that's
> distinct from the ultimate goal of better refactoring (especailly since
> that was one of the main goals of unifying development efforts)
>
> Here's my concrete suggestion that could be done today (for simplicity:
> $svn = https://svn.apache.org/repos/asf/lucene)...
>
> svn mv $svn/java/trunk $svn/java/tmp-migration
> svn mkdir $svn/java/trunk
> svn mv $svn/solr/trunk $svn/java/trunk/solr
> svn mv $svn/java/tmp-migration $svn/java/trunk/core
>
> At which point:
>
> 0. People who want to work only on "Lucene-Java" can start checking out
> $svn/java/trunk/core (i'm pretty sure existing checkouts will continue to
> work w/o any changes, the svn info should just update itself)
>
> 1. build files can be added to (the new) $svn/java/trunk to build ./core
> followed by ./solr
>
> 2. the build files in $svn/java/trunk/solr can be modified to look at
> ../core/ to find lucene jars
>
> 3. people who care about Solr (including all committers) should start
> checking out and building all of $svn/java/trunk
>
> 4. Long term, we could choose to branch all of $svn/java/trunk
> for releases ... AND/OR we could choose to branch specific modules
> (ie: solr) independently (with modifications to the build files on those
> branches to pull in their dependencies from alternate locations
>
> 5. Long term, we can start refactoring additional "modules" out of
> $svn/java/trunk/solr and $svn/java/trunk/core (like
> $svn/java/trunk/core/contrib) into their own directory in $svn/java/trunk
>
> 6. Long term, people who want to work on more then just "core" but don't
> care about certain "modules" (like solr) can do a simple non-recursive
> checkout of $svn/java/trunk and then do full checkouts of whatever modules
> they care about
>
>
> (Please note: I'm just trying to list things we *could* do if we go this
> route, i'm not advocating that we *should* do any of these things)
>
> I can't think of any objections people have raised to any of the previous
> suggestions which apply to this suggestion. Is there anything people can
> think of that would be useful, but not possible, if we go this route?
>
>
> -Hoss
>
>
--
- Mark
http://www.lucidimagination.com
Re: lucene and solr trunk
Posted by Jake Mannix <ja...@gmail.com>.
On Tue, Mar 16, 2010 at 3:46 PM, Chris Hostetter
<ho...@fucit.org>wrote:
> : Otis, yes, I think so, eventually. But that's gonna take much more
> discussion.
> :
> : I don't think this initial cutover should try to "solve" how modules
> : will be organized, yet... we'll get there, eventually.
>
> But we should at least consider it, and not move in a direction that's
> distinct from the ultimate goal of better refactoring (especailly since
> that was one of the main goals of unifying development efforts)
>
> Here's my concrete suggestion that could be done today (for simplicity:
> $svn = https://svn.apache.org/repos/asf/lucene)...
>
> svn mv $svn/java/trunk $svn/java/tmp-migration
> svn mkdir $svn/java/trunk
> svn mv $svn/solr/trunk $svn/java/trunk/solr
> svn mv $svn/java/tmp-migration $svn/java/trunk/core
>
>
Cool, I think this is what I was just saying in reference to mavenized
projects. Core and Solr are siblings of the "Lucene" project.
-jake
Re: lucene and solr trunk
Posted by Mark Miller <ma...@gmail.com>.
On 03/16/2010 06:46 PM, Chris Hostetter wrote:
>
> Here's my concrete suggestion that could be done today
+1
--
- Mark
http://www.lucidimagination.com
Re: lucene and solr trunk
Posted by Chris Hostetter <ho...@fucit.org>.
: Otis, yes, I think so, eventually. But that's gonna take much more discussion.
:
: I don't think this initial cutover should try to "solve" how modules
: will be organized, yet... we'll get there, eventually.
But we should at least consider it, and not move in a direction that's
distinct from the ultimate goal of better refactoring (especailly since
that was one of the main goals of unifying development efforts)
Here's my concrete suggestion that could be done today (for simplicity:
$svn = https://svn.apache.org/repos/asf/lucene)...
svn mv $svn/java/trunk $svn/java/tmp-migration
svn mkdir $svn/java/trunk
svn mv $svn/solr/trunk $svn/java/trunk/solr
svn mv $svn/java/tmp-migration $svn/java/trunk/core
At which point:
0. People who want to work only on "Lucene-Java" can start checking out
$svn/java/trunk/core (i'm pretty sure existing checkouts will continue to
work w/o any changes, the svn info should just update itself)
1. build files can be added to (the new) $svn/java/trunk to build ./core
followed by ./solr
2. the build files in $svn/java/trunk/solr can be modified to look at
../core/ to find lucene jars
3. people who care about Solr (including all committers) should start
checking out and building all of $svn/java/trunk
4. Long term, we could choose to branch all of $svn/java/trunk
for releases ... AND/OR we could choose to branch specific modules
(ie: solr) independently (with modifications to the build files on those
branches to pull in their dependencies from alternate locations
5. Long term, we can start refactoring additional "modules" out of
$svn/java/trunk/solr and $svn/java/trunk/core (like
$svn/java/trunk/core/contrib) into their own directory in $svn/java/trunk
6. Long term, people who want to work on more then just "core" but don't
care about certain "modules" (like solr) can do a simple non-recursive
checkout of $svn/java/trunk and then do full checkouts of whatever modules
they care about
(Please note: I'm just trying to list things we *could* do if we go this
route, i'm not advocating that we *should* do any of these things)
I can't think of any objections people have raised to any of the previous
suggestions which apply to this suggestion. Is there anything people can
think of that would be useful, but not possible, if we go this route?
-Hoss
Re: lucene and solr trunk
Posted by Michael McCandless <lu...@mikemccandless.com>.
Otis, yes, I think so, eventually. But that's gonna take much more discussion.
I don't think this initial cutover should try to "solve" how modules
will be organized, yet... we'll get there, eventually.
Mike
On Tue, Mar 16, 2010 at 4:57 PM, Otis Gospodnetic
<ot...@yahoo.com> wrote:
> Hi,
>
> Check out the dir structure mentioned here: http://markmail.org/message/gwpmaevw7tavqqge
>
> Isn't that what we want?
>
> Otis
> ----
> Sematext :: http://sematext.com/ :: Solr - Lucene - Nutch
> Hadoop ecosystem search :: http://search-hadoop.com/
>
>
>
> ----- Original Message ----
>> From: Mark Miller <ma...@gmail.com>
>> To: solr-dev@lucene.apache.org
>> Sent: Mon, March 15, 2010 11:43:48 PM
>> Subject: Re: lucene and solr trunk
>>
>> On 03/15/2010 11:28 PM, Yonik Seeley wrote:
>> So, we have a few options on
>> where to put Solr's new trunk:
>>
>>
>> Solr moves to Lucene's
>> trunk:
>> /java/trunk, /java/trunk/sol
> +1. With the goal of
>> merged dev, merged tests, this looks the best to
> me. Simple to do patches
>> that span both, simple to setup
> Solr to use Lucene trunk rather than jars.
>> Short paths. Simple. I like it.
>
> --
> - Mark
>
>
>> href="http://www.lucidimagination.com" target=_blank
>> >http://www.lucidimagination.com
>
Re: lucene and solr trunk
Posted by Otis Gospodnetic <ot...@yahoo.com>.
Hi,
Check out the dir structure mentioned here: http://markmail.org/message/gwpmaevw7tavqqge
Isn't that what we want?
Otis
----
Sematext :: http://sematext.com/ :: Solr - Lucene - Nutch
Hadoop ecosystem search :: http://search-hadoop.com/
----- Original Message ----
> From: Mark Miller <ma...@gmail.com>
> To: solr-dev@lucene.apache.org
> Sent: Mon, March 15, 2010 11:43:48 PM
> Subject: Re: lucene and solr trunk
>
> On 03/15/2010 11:28 PM, Yonik Seeley wrote:
> So, we have a few options on
> where to put Solr's new trunk:
>
>
> Solr moves to Lucene's
> trunk:
> /java/trunk, /java/trunk/sol
+1. With the goal of
> merged dev, merged tests, this looks the best to
me. Simple to do patches
> that span both, simple to setup
Solr to use Lucene trunk rather than jars.
> Short paths. Simple. I like it.
--
- Mark
> href="http://www.lucidimagination.com" target=_blank
> >http://www.lucidimagination.com
Re: lucene and solr trunk
Posted by Robert Muir <rc...@gmail.com>.
On Mon, Mar 15, 2010 at 11:43 PM, Mark Miller <ma...@gmail.com> wrote:
>>
>> Solr moves to Lucene's trunk:
>> /java/trunk, /java/trunk/sol
>
> +1. With the goal of merged dev, merged tests, this looks the best to me.
> Simple to do patches that span both, simple to setup
> Solr to use Lucene trunk rather than jars. Short paths. Simple. I like it.
>
+1
--
Robert Muir
rcmuir@gmail.com
Re: lucene and solr trunk
Posted by Mark Miller <ma...@gmail.com>.
On 03/15/2010 11:28 PM, Yonik Seeley wrote:
> So, we have a few options on where to put Solr's new trunk:
>
>
> Solr moves to Lucene's trunk:
> /java/trunk, /java/trunk/sol
+1. With the goal of merged dev, merged tests, this looks the best to
me. Simple to do patches that span both, simple to setup
Solr to use Lucene trunk rather than jars. Short paths. Simple. I like it.
--
- Mark
http://www.lucidimagination.com
Re: lucene and solr trunk
Posted by Chris Hostetter <ho...@fucit.org>.
: Yep, those users probably already hate our backwards tests and the
: contrib tests too.
probably ... which is just another reason why it probably makes sense
sense to move "core" stuff from Lucene-Java into it's own "module" along
side solr, and other modules that get refactored out of Solr or the
existing contribs.
But back to my first point: these types of issues are why some discussions
are warranted about what the plan should be for automated builds,
releasees, point-release branching, etc... before we pick a directory
structures.
"trunk" is nothing more then a convention in SVN, so we could decide that
Solr should live under /lucene/yatzee/solr and Lucene-Java should live
under /lucene/bigfoot/java, and branches and tags of both should live in
"/lucene/whatsallthisnow/somestuff, but if that doesn't actually make
progress any easier there's not much point. -- Likewise, ther's not much
point in picking between any of the other structures suggested so far
unless we have a clear idea how we're going to use them.
structure should follow function.
-Hoss
Re: lucene and solr trunk
Posted by Robert Muir <rc...@gmail.com>.
On Tue, Mar 16, 2010 at 12:39 AM, Chris Hostetter
<ho...@fucit.org> wrote:
> And as a committer, you should be concerned about things like this ...
> that doesn't mean every user of Lucene-Java who wants to build from source
> or apply their own local patches is going to feel the same way.
>
Yep, those users probably already hate our backwards tests and the
contrib tests too.
--
Robert Muir
rcmuir@gmail.com
Re: lucene and solr trunk
Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
Hi Hoss,
> : > (i suspect a whole lot of people who only care about the core library are
> : > going to really adamantly not want to have to check out all of Solr just
> : > to work on the core)
> :
> : This wouldn't really be merged development now would it?
> : When I run 'ant test' I want the Solr tests to run, too.
> : If one breaks because of a change, I want to look at the source and know
> why.
>
> And as a committer, you should be concerned about things like this ...
> that doesn't mean every user of Lucene-Java who wants to build from source
> or apply their own local patches is going to feel the same way.
+1. Personally, I'm one of those users and appreciate the separation in SVN.
Cheers,
Chris
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: Chris.Mattmann@jpl.nasa.gov
WWW: http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Re: lucene and solr trunk
Posted by Chris Hostetter <ho...@fucit.org>.
: > (i suspect a whole lot of people who only care about the core library are
: > going to really adamantly not want to have to check out all of Solr just
: > to work on the core)
:
: This wouldn't really be merged development now would it?
: When I run 'ant test' I want the Solr tests to run, too.
: If one breaks because of a change, I want to look at the source and know why.
And as a committer, you should be concerned about things like this ...
that doesn't mean every user of Lucene-Java who wants to build from source
or apply their own local patches is going to feel the same way.
-Hoss
Re: lucene and solr trunk
Posted by Robert Muir <rc...@gmail.com>.
On Tue, Mar 16, 2010 at 12:01 AM, Chris Hostetter
<ho...@fucit.org> wrote:
> 4) should it be possible for people to check out Lucene-Java w/o
> checking out Solr?
>
> (i suspect a whole lot of people who only care about the core library are
> going to really adamantly not want to have to check out all of Solr just
> to work on the core)
This wouldn't really be merged development now would it?
When I run 'ant test' I want the Solr tests to run, too.
If one breaks because of a change, I want to look at the source and know why.
--
Robert Muir
rcmuir@gmail.com
RE: lucene and solr trunk
Posted by Uwe Schindler <uw...@thetaphi.de>.
Hi,
> And Lucene is on Java 1.5 and should be compiled with an 1.5 compiler,
> where Solr seems to be on 1.6 since yesterday? (Yonik added something
> to common-build.xml). On my development system I have no Java 1.6
> installed at all as default build, I ever use Java 1.5 for building
> Lucene. If we merge that and have both on different JVMs the same
> problems like with 1.4/1.5 start. Developers use 1.6 methods because
> their compiler does not warn them. So everybody working on Lucene
> should at least have Java 1.5 compiler and try to compile his changes
> before committing. I do this (as I use 1.5 for developing), 1.6 on some
> of our servers.
>
> So: If merge, keep both on Java 1.5 !!!
I changed common-build.xml in the new solr branch to Java 1.5 again, as there is currently no reason to change this and especially as it was not discussed anywhere.
Java 1.5 as base for both solr and lucene is better and the few features of Java 1.6 does not rectify to move up. I have my development area configured with Java 1.5 and I only develop Lucene in 1.5. I am then sure to not use the wrong methods when creating patches. You can still tell users to run with JRE 1.6, but development should stay on 1.5 for now.
Uwe
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: lucene and solr trunk
Posted by Michael Busch <bu...@gmail.com>.
I completely agree with Uwe and Hoss. These questions need to be
addressed first.
I still want to be able to only checkout Lucene code and run the Lucene
build independently from Solr. And Lucene needs to be able to release
without Solr and the branching/tagging needs to support that as Uwe
points out.
Michael
On 3/16/10 12:18 AM, Uwe Schindler wrote:
> Hi all,
>
> I don't want to be against all other developers that voted +1 for the SVN "merge", but I am not happy with it. Most importantly for the reasons Hoss mentioned:
>
>
>> : prime-time as the new solr trunk! Lucene and Solr need to move to a
>> : common trunk for a host of reasons, including single patches that can
>> : cover both, shared tags and branches, and shared test code w/o a test
>> : jar.
>>
>> Without a clearer picture of how people envision development "overhead"
>> working as we move forward, it's really hard to understand how any of
>> these ideas make sense...
>> 1) how should hte automated build process(es) work?
>> 2) how are we going to do branching/tagging for releases?
>> particularly
>> in situations where one product is ready for a rlease and hte other
>> isn't?
>> 3) how are we going to deal with mino bug fix release tagging?
>> 4) should it be possible for people to check out Lucene-Java w/o
>> checking out Solr?
>>
> That are important questions and not simply to solve!
>
>
>> (i suspect a whole lot of people who only care about the core library
>> are
>> going to really adamantly not want to have to check out all of Solr
>> just
>> to work on the core)
>>
> Exactly! The Solr checkout is really huge because of thousands of JAR files and so on. The badest thing we could do would be to merge all those JARs into one general lib folder or like so. Please do not! Lucene-core should stay a lib without any external deps.
>
>
>> : Both projects move to a new trunk:
>> : /something/trunk/java, /something/trunk/solr
>>
> This would be the only optinon we have. This new folder could simply contain two dirs below and a build.xml in the top level that delegates and builds first lucene, then solr. But you can do this also with separate checkouts and a simple script downloaded from the wiki.
>
> The problems of this approach far overweigh the positive side:
>
> In the original vote, we said, Lucene can release without Solr:
> Releasing (I was the last release mangaer) contains things like creating branches and tags. In SVN, if you create a branch, you copy everything from under trunk (or another branch) to a new folder below branches (for tags under tags). "tags" on most SVN servers has an additional limittation, that it is not possible to change anything under "tags" except copying.
>
> If we have those combined trunk folder and Lucene wants to release and creates a branch/tag. Solr is enforced to do this too. OK, you could say, we just branch the folder lucene and let solr where it is. But that would be a against conventions and the branch checkout could not life alone.
>
> I just repeat: we wanted to merge devs and not codebase! And merging devs is a "code change" clearly.
>
> And Lucene is on Java 1.5 and should be compiled with an 1.5 compiler, where Solr seems to be on 1.6 since yesterday? (Yonik added something to common-build.xml). On my development system I have no Java 1.6 installed at all as default build, I ever use Java 1.5 for building Lucene. If we merge that and have both on different JVMs the same problems like with 1.4/1.5 start. Developers use 1.6 methods because their compiler does not warn them. So everybody working on Lucene should at least have Java 1.5 compiler and try to compile his changes before committing. I do this (as I use 1.5 for developing), 1.6 on some of our servers.
>
> So: If merge, keep both on Java 1.5 !!!
>
>
>> by gut says something like this will more the most sense, assuming
>> "/something/trunk" == "/java/trunk" and "java" actually means "core"
>> ...
>>
> And that is how it looks currently and I am fine with it!
>
>
>> ie: this discussion should really be part and parcel with how contribs
>> should be reorged.
>>
> That is exactly what should be done. Not now simply copy the folders somewhere for some "development simplification" that not really is one and opens more problems!
>
> I propose another idea for now until the "module" decision is [DISCUSS]ed and [VOTE]d:
>
> Lets create a new project folder with trunk and branches for combined trunk development in SVN (this can be later the folder for the module development). This folder simply contains a delegating build.xml (delegating the common tasks like build and test and so on to solr and trunk).The folder simply uses svn:external SVN props to link current solr and lucene trunk as subfolders. So developers that want to work on both can simply checkout this folder and SVN will resolve the externals. As this is trunk development, the externals will be without rev numbers and relative for the http(s) problem (SVN 1.5+ required).
>
> For testing flex, we create a branch of this folder, still pointing to solr-trunk, but flex branch in Lucene.
>
> One task of the main build.xml would be to copy all produced JAR files of Lucene into the correct build folder in Solr.
>
> I hope that you all understand me, but I am against merging trunks (for now) until we have a clear module decision.
>
> Uwe
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: lucene and solr trunk
Posted by Grant Ingersoll <gs...@apache.org>.
On Mar 16, 2010, at 3:51 AM, Michael Busch wrote:
> On 3/16/10 12:43 AM, Simon Willnauer wrote:Me too. I don't have the time to follow IRC in addition to jira and mailinglists. I know I've been missing stuff, because in the past I commented on jira issues and later was told that my questions were already discussed thoroughly on IRC. I've also seen jira issues that start with something like "Summary of IRC discussion:".
I too am troubled by the likes of this and have been feeling much the same way, as many already know. It is on my list of things to discuss with the community, but I was going to wait a week or so to send, to let the volume die down a bit.
-Grant
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: #lucene IRC log [was: RE: lucene and solr trunk]
Posted by Yonik Seeley <yo...@apache.org>.
IRC has been discussed to death at Apache:
http://markmail.org/search/?q=IRC+list%3Aorg.apache.incubator.general
Look for the spikes... like this:
http://markmail.org/search/?q=IRC+list%3Aorg.apache.incubator.general#query:IRC%20list%3Aorg.apache.incubator.general%20date%3A200608%20+page:1+state:facets
-Yonik
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: #lucene IRC log [was: RE: lucene and solr trunk]
Posted by Michael McCandless <lu...@mikemccandless.com>.
On Tue, Mar 16, 2010 at 2:17 PM, Michael Busch <bu...@gmail.com> wrote:
> But at the same time can we make sure that the decisions that are made on
> IRC are still being described in a jira issue?
+1
Any time something is discussed on IRC, it must be summarized on the
lists or in an issue, with the details based on what was discussed, or
else it didn't happen....
IRC is a great way to hash out ideas, brainstorm, shoot the breeze,
vent, etc. Much of what's discussed doesn't pan out... but when stuff
does we always bring to the lists...
Those of us spending some time on IRC have been trying to do exactly
that. Maybe we've been falling short sometimes, not providing enough
detail, so we should fix that with time. We're all still learning as
we go...
Also: if an issue is opened and it's missing details, regardless of
whether it was born in IRC or some other place, people should simply
ask questions, punch holes, etc. When another set of eyes, or the
same set of eyes some time later, look at the issue, very different
and healthy iterations happen. Most certainly if something seems like
a good idea during IRC discussions that doesn't not mean the debate is
done -- rather the issue is opened and lots of other people chime in.
Nothing is "decided" on IRC... only ideas are born... that's all.
Stepping back, Lucene/Solr are clearly at a fast pace of innovation
right now, and this is really very healthy. It'd already been fast a
few months ago, but it seems to be accelerating... I think that's
because suddenly we have quite a few strong [near-] full-time devs
here, and, because IRC allows for real-time conversations for
brainstorming.
This is net/net good for both Lucene and Solr and I think we should
try to find a way to make IRC work well so devs that do happen to
have the time (and, the list will change with time -- bright stars never
shine for long) can brainstorm and bring new ideas to the community...
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: #lucene IRC log [was: RE: lucene and solr trunk]
Posted by Michael Busch <bu...@gmail.com>.
It be very cool to have a searchable archive for the IRC discussions, so +1.
But at the same time can we make sure that the decisions that are made
on IRC are still being described in a jira issue? I don't mean that
people should repeat brainstorming, but if a discussion leads to opening
a Jira issue it'd be good to understand the reasons and details without
having to search the IRC log. Only if someone wants to know more, e.g.
what lead to the discussion, what other ideas were discarded, etc.
should have to go to the IRC log.
Michael
On 3/16/10 11:58 AM, Michael McCandless wrote:
> +1, this looks great!
>
> Mike
>
> On Tue, Mar 16, 2010 at 1:52 PM, Andi Vajda<va...@osafoundation.org> wrote:
>
>> On Mar 16, 2010, at 11:47, Steven A Rowe<sa...@syr.edu> wrote:
>>
>>
>>> On 03/16/2010 at 6:06 AM, Michael McCandless wrote:
>>>
>>>> Does anyone know how other projects fold in IRC...?
>>>>
>>> I gather from the deafening silence that we'll have to figure it out as we
>>> go...
>>>
>>> I think some (not all) of the discomfort associated with IRC could be
>>> addressed with a permanent, searchable, linkable archive of #lucene.
>>>
>>> I went looking for IRC loggers and found http://colabti.org/. One of the
>>> things hosted there is a searchable, linkable permanent archive of several
>>> freenode channels. I posted on #irclogger asking about hosting #lucene
>>> archive, and apparently all we have to do is ask, after first determining
>>> that nobody objects. Here's a link (not incidentally, this is exactly what
>>> we will have for #lucene once the service is switched on):
>>>
>>> http://colabti.org/irclogger/irclogger_log/irclogger?date=2010-03-16#l2
>>>
>>> So, would anybody participating on #lucene object to a permanent archive?
>>>
>> No objections on my part. I think this is essential.
>>
>> Andi..
>>
>>
>>> (I'm also going to provide a link to this thread on #lucene to make sure
>>> everybody there knows about the issue.)
>>>
>>> Steve
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
>>> For additional commands, e-mail: java-dev-help@lucene.apache.org
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: java-dev-help@lucene.apache.org
>>
>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: #lucene IRC log [was: RE: lucene and solr trunk]
Posted by Michael McCandless <lu...@mikemccandless.com>.
+1, this looks great!
Mike
On Tue, Mar 16, 2010 at 1:52 PM, Andi Vajda <va...@osafoundation.org> wrote:
>
> On Mar 16, 2010, at 11:47, Steven A Rowe <sa...@syr.edu> wrote:
>
>> On 03/16/2010 at 6:06 AM, Michael McCandless wrote:
>>>
>>> Does anyone know how other projects fold in IRC...?
>>
>> I gather from the deafening silence that we'll have to figure it out as we
>> go...
>>
>> I think some (not all) of the discomfort associated with IRC could be
>> addressed with a permanent, searchable, linkable archive of #lucene.
>>
>> I went looking for IRC loggers and found http://colabti.org/. One of the
>> things hosted there is a searchable, linkable permanent archive of several
>> freenode channels. I posted on #irclogger asking about hosting #lucene
>> archive, and apparently all we have to do is ask, after first determining
>> that nobody objects. Here's a link (not incidentally, this is exactly what
>> we will have for #lucene once the service is switched on):
>>
>> http://colabti.org/irclogger/irclogger_log/irclogger?date=2010-03-16#l2
>>
>> So, would anybody participating on #lucene object to a permanent archive?
>
> No objections on my part. I think this is essential.
>
> Andi..
>
>>
>> (I'm also going to provide a link to this thread on #lucene to make sure
>> everybody there knows about the issue.)
>>
>> Steve
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: java-dev-help@lucene.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: #lucene IRC log [was: RE: lucene and solr trunk]
Posted by Andi Vajda <va...@osafoundation.org>.
On Mar 16, 2010, at 11:47, Steven A Rowe <sa...@syr.edu> wrote:
> On 03/16/2010 at 6:06 AM, Michael McCandless wrote:
>> Does anyone know how other projects fold in IRC...?
>
> I gather from the deafening silence that we'll have to figure it out
> as we go...
>
> I think some (not all) of the discomfort associated with IRC could
> be addressed with a permanent, searchable, linkable archive of
> #lucene.
>
> I went looking for IRC loggers and found http://colabti.org/. One
> of the things hosted there is a searchable, linkable permanent
> archive of several freenode channels. I posted on #irclogger asking
> about hosting #lucene archive, and apparently all we have to do is
> ask, after first determining that nobody objects. Here's a link
> (not incidentally, this is exactly what we will have for #lucene
> once the service is switched on):
>
> http://colabti.org/irclogger/irclogger_log/irclogger?
> date=2010-03-16#l2
>
> So, would anybody participating on #lucene object to a permanent
> archive?
No objections on my part. I think this is essential.
Andi..
>
> (I'm also going to provide a link to this thread on #lucene to make
> sure everybody there knows about the issue.)
>
> Steve
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: #lucene IRC log [was: RE: lucene and solr trunk]
Posted by Marvin Humphrey <ma...@rectangular.com>.
On Tue, Mar 23, 2010 at 01:30:42PM -0700, Otis Gospodnetic wrote:
> Archiving the logs feels like it would be useful, but realistically
> speaking, they would be pretty big and who has the time to read them after
> the fact?
Someone who participated in the chat reviewing it while preparing a summary.
Marvin Humphrey
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: #lucene IRC log [was: RE: lucene and solr trunk]
Posted by Otis Gospodnetic <ot...@yahoo.com>.
Uh, the IRC logs... Do people really think making those *searchable* would be useful?
I think they'd be *extremely* noisy and hard to interpret without a person really just sequentially reading them. Lots of people talking at the same time, multiple topics, lots of very short intertwined messages that always need a lot of context, aren't threadable, etc.
Archiving the logs feels like it would be useful, but realistically speaking, they would be pretty big and who has the time to read them after the fact? You guys all read the recent issue of The Economist, right? ;)
Otis
----
Sematext :: http://sematext.com/ :: Solr - Lucene - Nutch
Lucene ecosystem search :: http://search-lucene.com/
>
>From: Ian Holsman <li...@holsman.net>
>To: java-dev@lucene.apache.org
>Sent: Thu, March 18, 2010 1:47:56 AM
>Subject: Re: #lucene IRC log [was: RE: lucene and solr trunk]
>
> >
>
>
>
>
>+1
>
>>I'd like to see the IRC logs added to things like
>
>http://search-lucene.com/ and
>
>http://www.lucidimagination.com/search/?q=IRC&Search=Search
>
>>while it might not be great for decision making.. it is amazing for
>helping debug common problems people have
>
>>On 3/17/10 7:10 AM, Chris Hostetter wrote:
>
>: with, "if id didn't happen on the lists, it didn't happen". Its the same as
>>
>>+1
>>
>>But as the IRC channel gets used more and more, it would *also* be nice if
>>there was an archive of the IRC channel so that there is a place to go
>>look to understand the back story behind an idea once it's synthesized and
>>posted to the lists/jira.
>>
>>That's the huge advantage IRC has over informal conversations at
>>hackathons, apachecon, and meetups -- there can in fact be easily
>>archivable/parsable/searchable records of the communication.
>>
>>
>>
>>-Hoss
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
>>For additional commands, e-mail: java-dev-help@lucene.apache.org
>>
>>
>
Re: #lucene IRC log [was: RE: lucene and solr trunk]
Posted by Ian Holsman <li...@holsman.net>.
+1
I'd like to see the IRC logs added to things like
http://search-lucene.com/ and
http://www.lucidimagination.com/search/?q=IRC&Search=Search
<http://www.lucidimagination.com/search/?q=IRC&Search=Search>
while it might not be great for decision making.. it is amazing for
helping debug common problems people have
On 3/17/10 7:10 AM, Chris Hostetter wrote:
> : with, "if id didn't happen on the lists, it didn't happen". Its the same as
>
> +1
>
> But as the IRC channel gets used more and more, it would *also* be nice if
> there was an archive of the IRC channel so that there is a place to go
> look to understand the back story behind an idea once it's synthesized and
> posted to the lists/jira.
>
> That's the huge advantage IRC has over informal conversations at
> hackathons, apachecon, and meetups -- there can in fact be easily
> archivable/parsable/searchable records of the communication.
>
>
>
> -Hoss
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
>
>
Re: #lucene IRC log [was: RE: lucene and solr trunk]
Posted by Chris Hostetter <ho...@fucit.org>.
: with, "if id didn't happen on the lists, it didn't happen". Its the same as
+1
But as the IRC channel gets used more and more, it would *also* be nice if
there was an archive of the IRC channel so that there is a place to go
look to understand the back story behind an idea once it's synthesized and
posted to the lists/jira.
That's the huge advantage IRC has over informal conversations at
hackathons, apachecon, and meetups -- there can in fact be easily
archivable/parsable/searchable records of the communication.
-Hoss
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: #lucene IRC log [was: RE: lucene and solr trunk]
Posted by Grant Ingersoll <gs...@apache.org>.
On Mar 16, 2010, at 3:24 PM, Mark Miller wrote:
> On 03/16/2010 02:57 PM, Grant Ingersoll wrote:
>> On Mar 16, 2010, at 2:47 PM, Steven A Rowe wrote:
>>
>>
>>> On 03/16/2010 at 6:06 AM, Michael McCandless wrote:
>>>
>>>> Does anyone know how other projects fold in IRC...?
>>>>
>>> I gather from the deafening silence that we'll have to figure it out as we go...
>>>
>>> I think some (not all) of the discomfort associated with IRC could be addressed with a permanent, searchable, linkable archive of #lucene.
>>>
>>> I went looking for IRC loggers and found http://colabti.org/. One of the things hosted there is a searchable, linkable permanent archive of several freenode channels. I posted on #irclogger asking about hosting #lucene archive, and apparently all we have to do is ask, after first determining that nobody objects. Here's a link (not incidentally, this is exactly what we will have for #lucene once the service is switched on):
>>>
>>> http://colabti.org/irclogger/irclogger_log/irclogger?date=2010-03-16#l2
>>>
>>> So, would anybody participating on #lucene object to a permanent archive?
>>>
>>> (I'm also going to provide a link to this thread on #lucene to make sure everybody there knows about the issue.)
>>>
>> There's also a lot of chatter that happens on IRC, so logging is going to have a lot of noise. I'm still on the fence on what to do. I don't want to get in people's way, but we also need to have traceability about decisions, and we certainly can't have answers like "We discussed this on IRC and you missed it, too bad" happening (not saying that has happening, just saying I don't want to see it).
>>
>> -Grant
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: java-dev-help@lucene.apache.org
>>
>>
>
> Even with logging, I'm against using IRC for making decisions, or as something people can point to. Even with searchable logging, I think we should stick with, "if id didn't happen on the lists, it didn't happen". Its the same as when some of us get together and talk about Lucene and Solr - thats great stuff - you can get a lot done that is a lot harder on the lists - you can hash a lot out. But I think people should always have the right to act like it didn't happen - the same as if we are at ApacheCon or something - we don't come back and say, sorry, you missed all the discussion, but we had one and this what we are going to do. We summarize the discussion on the list (like Mike likes to do with IRC), and answer questions as people have them. I personally think its great to come to mini agreements with real-time talk - then it just has to make its way through the list.
>
> This isn't a counter point to anything you said Grant, just a nice place for me to drop this.
>
+1. The ApacheCon talks are a great example of bringing back off list stuff to the list.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: #lucene IRC log [was: RE: lucene and solr trunk]
Posted by Mark Miller <ma...@gmail.com>.
On 03/16/2010 02:57 PM, Grant Ingersoll wrote:
> On Mar 16, 2010, at 2:47 PM, Steven A Rowe wrote:
>
>
>> On 03/16/2010 at 6:06 AM, Michael McCandless wrote:
>>
>>> Does anyone know how other projects fold in IRC...?
>>>
>> I gather from the deafening silence that we'll have to figure it out as we go...
>>
>> I think some (not all) of the discomfort associated with IRC could be addressed with a permanent, searchable, linkable archive of #lucene.
>>
>> I went looking for IRC loggers and found http://colabti.org/. One of the things hosted there is a searchable, linkable permanent archive of several freenode channels. I posted on #irclogger asking about hosting #lucene archive, and apparently all we have to do is ask, after first determining that nobody objects. Here's a link (not incidentally, this is exactly what we will have for #lucene once the service is switched on):
>>
>> http://colabti.org/irclogger/irclogger_log/irclogger?date=2010-03-16#l2
>>
>> So, would anybody participating on #lucene object to a permanent archive?
>>
>> (I'm also going to provide a link to this thread on #lucene to make sure everybody there knows about the issue.)
>>
> There's also a lot of chatter that happens on IRC, so logging is going to have a lot of noise. I'm still on the fence on what to do. I don't want to get in people's way, but we also need to have traceability about decisions, and we certainly can't have answers like "We discussed this on IRC and you missed it, too bad" happening (not saying that has happening, just saying I don't want to see it).
>
> -Grant
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
>
Even with logging, I'm against using IRC for making decisions, or as
something people can point to. Even with searchable logging, I think we
should stick with, "if id didn't happen on the lists, it didn't happen".
Its the same as when some of us get together and talk about Lucene and
Solr - thats great stuff - you can get a lot done that is a lot harder
on the lists - you can hash a lot out. But I think people should always
have the right to act like it didn't happen - the same as if we are at
ApacheCon or something - we don't come back and say, sorry, you missed
all the discussion, but we had one and this what we are going to do. We
summarize the discussion on the list (like Mike likes to do with IRC),
and answer questions as people have them. I personally think its great
to come to mini agreements with real-time talk - then it just has to
make its way through the list.
This isn't a counter point to anything you said Grant, just a nice place
for me to drop this.
--
- Mark
http://www.lucidimagination.com
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: #lucene IRC log [was: RE: lucene and solr trunk]
Posted by Grant Ingersoll <gs...@apache.org>.
On Mar 16, 2010, at 2:47 PM, Steven A Rowe wrote:
> On 03/16/2010 at 6:06 AM, Michael McCandless wrote:
>> Does anyone know how other projects fold in IRC...?
>
> I gather from the deafening silence that we'll have to figure it out as we go...
>
> I think some (not all) of the discomfort associated with IRC could be addressed with a permanent, searchable, linkable archive of #lucene.
>
> I went looking for IRC loggers and found http://colabti.org/. One of the things hosted there is a searchable, linkable permanent archive of several freenode channels. I posted on #irclogger asking about hosting #lucene archive, and apparently all we have to do is ask, after first determining that nobody objects. Here's a link (not incidentally, this is exactly what we will have for #lucene once the service is switched on):
>
> http://colabti.org/irclogger/irclogger_log/irclogger?date=2010-03-16#l2
>
> So, would anybody participating on #lucene object to a permanent archive?
>
> (I'm also going to provide a link to this thread on #lucene to make sure everybody there knows about the issue.)
There's also a lot of chatter that happens on IRC, so logging is going to have a lot of noise. I'm still on the fence on what to do. I don't want to get in people's way, but we also need to have traceability about decisions, and we certainly can't have answers like "We discussed this on IRC and you missed it, too bad" happening (not saying that has happening, just saying I don't want to see it).
-Grant
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
#lucene IRC log [was: RE: lucene and solr trunk]
Posted by Steven A Rowe <sa...@syr.edu>.
On 03/16/2010 at 6:06 AM, Michael McCandless wrote:
> Does anyone know how other projects fold in IRC...?
I gather from the deafening silence that we'll have to figure it out as we go...
I think some (not all) of the discomfort associated with IRC could be addressed with a permanent, searchable, linkable archive of #lucene.
I went looking for IRC loggers and found http://colabti.org/. One of the things hosted there is a searchable, linkable permanent archive of several freenode channels. I posted on #irclogger asking about hosting #lucene archive, and apparently all we have to do is ask, after first determining that nobody objects. Here's a link (not incidentally, this is exactly what we will have for #lucene once the service is switched on):
http://colabti.org/irclogger/irclogger_log/irclogger?date=2010-03-16#l2
So, would anybody participating on #lucene object to a permanent archive?
(I'm also going to provide a link to this thread on #lucene to make sure everybody there knows about the issue.)
Steve
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: lucene and solr trunk
Posted by Michael McCandless <lu...@mikemccandless.com>.
On Tue, Mar 16, 2010 at 2:51 AM, Michael Busch <bu...@gmail.com> wrote:
> On 3/16/10 12:43 AM, Simon Willnauer wrote:
>>
>> If my impression should be wrong or if I miss something please ignore
>> the last paragraph.
>
> I feel exactly like you, Simon. I don't understand the rush. Also, we're
> in review-and-commit process, not commit-and-review. Changes have to be
> proposed, discussed and ideally attached to jira as patches first.
There's obviously alot of excitement driving the progress here, and
there's been awesome progress. Things are moving fast, but...
Remember that all commits/fast iterations are being done on a branch,
so that people involved can make fast progress.
When we land that branch onto trunk, there will be the usual scrutiny
("review then commit") of the changes that're going in, and this email
was started to get the most important topic ("where does all this
land, anyway") going, first.
EG changes like a move to Java 1.6, disallowing compression in Solr's
schema.xml, the Version changes percolating into Solr, all obviously
need sizable review & discussion...
>> BTW: I still have the impression that if I don't follow IRC constantly
>> I'm missing important things.
>
> Me too. I don't have the time to follow IRC in addition to jira and
> mailinglists. I know I've been missing stuff, because in the past I
> commented on jira issues and later was told that my questions were already
> discussed thoroughly on IRC. I've also seen jira issues that start with
> something like "Summary of IRC discussion:".
This is a hard problem...
IRC is a very good tool to enable those that have the time (and I
agree it's ALOT OF TIME -- I can't keep up with it either) to work
together. Fast design discussions are a powerful way to bat around
random ideas, and I'd say IRC has already produced a number of good
ideas for improving Lucene (opened as issues, lately...).
But the thing to remember is of all the crazy discussions that happen
on IRC (and there are MANY that don't pan out), when a "real" idea
pans out, it must then go through the normal process -- turn into an
issue, comments are added summarizing the pros/cons that were
discussed on IRC, a patch is created and must be reviewed, iterated,
and then committed. The CTR process is still intact... it's just that
IRC is a faster way for some devs to discuss things that may turn into
real ideas (or, may get dropped on the floor).
Does anyone know how other projects fold in IRC...?
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: lucene and solr trunk
Posted by Shai Erera <se...@gmail.com>.
Hi
My only concern w/ how SVN might end up organized is that I'll still be able
checkout core lucene independently of Solr (and possibly contrib/modules)
and then build and test it. Also a separate project in Eclipse is important
as well.
How about this structure:
<root>/solr/trunk
<root>/lucene/trunk
<root>/modules/trunk
<root> can be left out if we don't think it's necessary.
This should allow us to:
1) Release each and everyone of them independently
2) Introduce dependencies between modules -> lucene and Solr -> modules +
lucene as, IMO, it should be. Lucene is core, modules extends it and Solr
extends and uses both.
3) Allow one to checkout exactly what it needs to work on.
4) Modules will always depend on a certain lucene version, either a cut
release or trunk. When it's released, its build.xml will be changed as part
of the release process to point to the lucene release (not trunk!) it
supports and depends on.
5) Same for Solr.
When a patch for Solr needs to change code in lucene, it is done it both, by
two different patches. Both are committed within the same issue. Since each
trunk can depends on the other's trunk, this shouldn't be a problem.
Indeed, it will complicate a bit the build.xmls - like it's done today for
core lucene and backwards. But that's ok I think. I don't expect all Solr
issues to require a change in lucene as well as not all modules issues will.
So that change to the build.xml should not be a frequent operation.
Another thing this will change (and I think for the better) is that a Solr
release might require cutting a Lucene and modules ones, and I think we
should be flexible about that. This also is not something I think will be
frequent ... like today, Solr could still be limited to a certain lucene
release or trunk revision.
I still this is still in line w/ one project, one codebase, just different
levels of the really big parts (Solr, lucene and modules). Committers can be
given access to <root> which will give them access to everything. Others
(modules-committers) can be given access to just that folder (hijacking a
bit from the other thread).
The flexibility of being able to checkout lucene code only is important, at
least to me. I wouldn't want to lose it.
On the IRC stuff - I know that we cannot prevent anyone from discussing on
issues anywhere, and I respect that freedom. It's just that some time ago I
was told that I shouldn't hold 'private' discussions on Lucene, outside the
community. I know that this IRC channel, that's called #lucene, is not
completely outside the community, but here's how it looks to the outsider
(not on IRC):
1) An issue is opened w/ comment "summarizing discussion on IRC ...".
2) Then a couple of hours later (or days), new comment: "more discussion
summary on IRC".
3) Then some comment, some that are not on IRC
4) Then more comment (from an IRC-er): "ok we've discussed this and here's
what we came up with ..."
Feels like we're on a need to know basis here. Remember that when a
discussion is fully open, you might have some comments on what was said in
the process. When you are given the final decision, or a summary, you cannot
comment on what you weren't told. That's a bit frustrating ... though I'm
trying very hard to be involved w/ the mailing list, it feels like I miss
TONS of discussions on IRC ... and what seems worse (as I read somewhere in
the thread) is that you can open an issue w/ an idea (like happened to me),
just to discover the folks on IRC took it all the way to design and impl
proposals, and I was left to read the summarization ...
So by no means am I trying to suggest that IRC discussions should stop. As I
don't, can't and won't ever have control on that. Just like I cannot keep
two people sitting in next rooms to discuss on issues or Lucene outside the
list. But I'd feel better if when a discussion makes it to the list or an
issue, it'd be conducted there from now on, and not as snippets/summaries of
the IRC discussion. Can we keep at least that?
I don't want to get people off their seats w/ that request :). I'm not even
sure I'm in a position to make such requests :). But I'd appreciate if it
can be at least discussed (not on IRC).
Shai
On Tue, Mar 16, 2010 at 5:48 PM, Grant Ingersoll <gs...@apache.org>wrote:
>
> On Mar 16, 2010, at 10:18 AM, Mark Miller wrote:
>
> > On 03/16/2010 10:09 AM, Yonik Seeley wrote:
> >> On Tue, Mar 16, 2010 at 2:51 AM, Michael Busch<bu...@gmail.com>
> wrote:
> >>
> >>> Also, we're in review-and-commit process, not commit-and-review.
> Changes have to be
> >>> proposed, discussed and ideally attached to jira as patches first.
> >>>
> >> Correction, just for the sake of avoiding future confusion (i.e. I'm
> >> not making any point about this thread):
> >>
> >> Lucene and Solr have always officially been CTR.
> >> For trunk, we normally use a bit of informal lazy consensus for
> >> anything big, hard, or that might be controvertial... but we are not
> >> officially RTC.
> >>
> >> -Yonik
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> >> For additional commands, e-mail: java-dev-help@lucene.apache.org
> >>
> >>
> >
> > In any case, this is a branch. People really want to enforce RTC on a
> branch??? Even if that was our official process on trunk (which I agree it
> has not been) that's not how the flex branch worked. That's not how the
> solr_cloud branch worked. That's not how other previous branches have
> worked.
> >
> > IMO - anyone should be able to create a branch for anything - to play
> around with whatever they want. We should encourage this. Branches are good.
> And they take up little space.
> >
>
> +1. Furthermore, it is incumbent on the people working on the branch to
> then present and discuss when/how to merge to trunk, just like any big
> patch.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
>
Re: lucene and solr trunk
Posted by Grant Ingersoll <gs...@apache.org>.
On Mar 16, 2010, at 10:18 AM, Mark Miller wrote:
> On 03/16/2010 10:09 AM, Yonik Seeley wrote:
>> On Tue, Mar 16, 2010 at 2:51 AM, Michael Busch<bu...@gmail.com> wrote:
>>
>>> Also, we're in review-and-commit process, not commit-and-review. Changes have to be
>>> proposed, discussed and ideally attached to jira as patches first.
>>>
>> Correction, just for the sake of avoiding future confusion (i.e. I'm
>> not making any point about this thread):
>>
>> Lucene and Solr have always officially been CTR.
>> For trunk, we normally use a bit of informal lazy consensus for
>> anything big, hard, or that might be controvertial... but we are not
>> officially RTC.
>>
>> -Yonik
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: java-dev-help@lucene.apache.org
>>
>>
>
> In any case, this is a branch. People really want to enforce RTC on a branch??? Even if that was our official process on trunk (which I agree it has not been) that's not how the flex branch worked. That's not how the solr_cloud branch worked. That's not how other previous branches have worked.
>
> IMO - anyone should be able to create a branch for anything - to play around with whatever they want. We should encourage this. Branches are good. And they take up little space.
>
+1. Furthermore, it is incumbent on the people working on the branch to then present and discuss when/how to merge to trunk, just like any big patch.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: lucene and solr trunk
Posted by Mark Miller <ma...@gmail.com>.
On 03/16/2010 10:09 AM, Yonik Seeley wrote:
> On Tue, Mar 16, 2010 at 2:51 AM, Michael Busch<bu...@gmail.com> wrote:
>
>> Also, we're in review-and-commit process, not commit-and-review. Changes have to be
>> proposed, discussed and ideally attached to jira as patches first.
>>
> Correction, just for the sake of avoiding future confusion (i.e. I'm
> not making any point about this thread):
>
> Lucene and Solr have always officially been CTR.
> For trunk, we normally use a bit of informal lazy consensus for
> anything big, hard, or that might be controvertial... but we are not
> officially RTC.
>
> -Yonik
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
>
In any case, this is a branch. People really want to enforce RTC on a
branch??? Even if that was our official process on trunk (which I agree
it has not been) that's not how the flex branch worked. That's not how
the solr_cloud branch worked. That's not how other previous branches
have worked.
IMO - anyone should be able to create a branch for anything - to play
around with whatever they want. We should encourage this. Branches are
good. And they take up little space.
Branch changes have to be proposed, discussed, and attached to JIRA?
Uggg - I certainly hope not.
Branches should be considered replacements for huge unwieldy patches. Do
I have to propose and discuss before I put up a patch?
--
- Mark
http://www.lucidimagination.com
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: lucene and solr trunk
Posted by Yonik Seeley <ys...@gmail.com>.
On Tue, Mar 16, 2010 at 2:51 AM, Michael Busch <bu...@gmail.com> wrote:
> Also, we're in review-and-commit process, not commit-and-review. Changes have to be
> proposed, discussed and ideally attached to jira as patches first.
Correction, just for the sake of avoiding future confusion (i.e. I'm
not making any point about this thread):
Lucene and Solr have always officially been CTR.
For trunk, we normally use a bit of informal lazy consensus for
anything big, hard, or that might be controvertial... but we are not
officially RTC.
-Yonik
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: lucene and solr trunk
Posted by Michael Busch <bu...@gmail.com>.
On 3/16/10 12:43 AM, Simon Willnauer wrote:
> If my impression should be wrong or if I miss something please ignore
> the last paragraph.
>
I feel exactly like you, Simon. I don't understand the rush. Also,
we're in review-and-commit process, not commit-and-review. Changes have
to be proposed, discussed and ideally attached to jira as patches first.
> BTW: I still have the impression that if I don't follow IRC constantly
> I'm missing important things.
>
>
Me too. I don't have the time to follow IRC in addition to jira and
mailinglists. I know I've been missing stuff, because in the past I
commented on jira issues and later was told that my questions were
already discussed thoroughly on IRC. I've also seen jira issues that
start with something like "Summary of IRC discussion:".
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: lucene and solr trunk
Posted by Erick Erickson <er...@gmail.com>.
My snap impression is that moving lucene to a sub-tree
under SOLR would introduce some confusion in the minds
of new folks looking at the code. *We* all know that Lucene
stands by itself, but putting it under a solr makes that less
obvious. I claim that there would be questions like "so can
I just use Lucene without SOLR?".
That said, the questions about release management, branching,
tagging, etc. take complete precedence over minor
confusion when the answer is "just go to directory X and
checkout if you want Lucene only".
FWIW
Erick
On Tue, Mar 16, 2010 at 8:30 AM, Robert Muir <rc...@gmail.com> wrote:
> On Tue, Mar 16, 2010 at 3:43 AM, Simon Willnauer
> <si...@googlemail.com> wrote:
>
> > One more thing which I wonder about even more is that this whole
> > merging happens so quickly for reasons I don't see right now. I don't
> > want to keep anybody from making progress but it appears like a rush
> > to me.
>
>
> By the way, the serious changes we applied to the branch, most of them
> have been sitting in JIRA over 3 months not doing much: SOLR-1659
>
> if you follow the linked issues, you can see all the stuff that got
> put in the branch... the branch was helpful for me, as I could help
> Mark with the "ton of little things", like TokenStreams embedded
> inside JSP files :)
>
> As its just a branch, if you want to go look at those patches
> (especially anything I did) and provide technical feedback, that would
> be great!
>
> But I think its a mistake to say things are rushed when the work has
> been done for months.
>
> --
> Robert Muir
> rcmuir@gmail.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
>
Re: lucene and solr trunk
Posted by Robert Muir <rc...@gmail.com>.
On Tue, Mar 16, 2010 at 3:43 AM, Simon Willnauer
<si...@googlemail.com> wrote:
> One more thing which I wonder about even more is that this whole
> merging happens so quickly for reasons I don't see right now. I don't
> want to keep anybody from making progress but it appears like a rush
> to me.
By the way, the serious changes we applied to the branch, most of them
have been sitting in JIRA over 3 months not doing much: SOLR-1659
if you follow the linked issues, you can see all the stuff that got
put in the branch... the branch was helpful for me, as I could help
Mark with the "ton of little things", like TokenStreams embedded
inside JSP files :)
As its just a branch, if you want to go look at those patches
(especially anything I did) and provide technical feedback, that would
be great!
But I think its a mistake to say things are rushed when the work has
been done for months.
--
Robert Muir
rcmuir@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: lucene and solr trunk
Posted by Stefan Trcek <wz...@abas.de>.
On Tuesday 16 March 2010 14:12:20 Mark Miller wrote:
> On 03/16/2010 09:05 AM, Andrzej Bialecki wrote:
> >
> > You could have used git instead. There is a good integration
> > between git and svn, and it's much easier (a giant
> > understatement...) to handle branching and merging in git, both
> > between git branches and syncing with external svn.
>
> Yeah, we have actually discussed doing things like GIT in the past -
> prob main reason we didn't is learning curve at the moment. I haven't
> used it yet.
I jumped off perforce by using a git-perforce bridge for daily work.
This made me comfortable with git while not changing anything public.
And I had the certainty that if anything goes wrong, I can do it in
perforce. Meanwhile we migrated a 2GB trunk sources repo from a legacy
repo to git and it works fine. So don't hesitate do use a git-svn
bridge.
git will open new modes of operation, e.g. instead of up- and
downloading patches in jira just hold a branch for any patch in a repo,
which is as public as jira, batch-upgrade that branches/patches to
trunk and pull that branches into the core developers repo as desired.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: lucene and solr trunk
Posted by Mark Miller <ma...@gmail.com>.
On 03/16/2010 09:05 AM, Andrzej Bialecki wrote:
> On 2010-03-16 12:29, Mark Miller wrote:
>
>> From our perspective, we would have been just as happy with a branch on
>> my local hard drive! That would have taken longer to setup though.
>
> You could have used git instead. There is a good integration between
> git and svn, and it's much easier (a giant understatement...) to
> handle branching and merging in git, both between git branches and
> syncing with external svn.
>
Yeah, we have actually discussed doing things like GIT in the past -
prob main reason we didn't is learning curve at the moment. I haven't
used it yet.
--
- Mark
http://www.lucidimagination.com
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: lucene and solr trunk
Posted by Andrzej Bialecki <ab...@getopt.org>.
On 2010-03-16 12:29, Mark Miller wrote:
> From our perspective, we would have been just as happy with a branch on
> my local hard drive! That would have taken longer to setup though.
You could have used git instead. There is a good integration between git
and svn, and it's much easier (a giant understatement...) to handle
branching and merging in git, both between git branches and syncing with
external svn.
--
Best regards,
Andrzej Bialecki <><
___. ___ ___ ___ _ _ __________________________________
[__ || __|__/|__||\/| Information Retrieval, Semantic Web
___|||__|| \| || | Embedded Unix, System Integration
http://www.sigram.com Contact: info at sigram dot com
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: lucene and solr trunk
Posted by Mark Miller <ma...@gmail.com>.
On 03/16/2010 07:05 AM, Shalin Shekhar Mangar wrote:
>
> Wow, you guys are moving fast! Thats a good thing.
>
> IRC is fine if you want to discuss something quickly. But it has its
> limitations. For example, I cannot follow IRC most of the times
> because I'm in a different time zone. But I don't want to stop anyone
> either. In fact, I can't do that. Nobody can.
>
> All I want to say is that once discussions have happened and a plan
> agreed upon, it may be a good idea to let solr-dev/java-dev know the
> plan. In this case I didn't know a new branch was created until I saw
> was a commit notification and then Yonik's email.
>
Hi Shalin - I like your attitude ;)
-
Yonik's email was the notification of the plan :) Though we had no plan.
When Robert and I made the branch we had no plan really - we just needed
a place to put together our patches and do the final work. We were
trying to do it with patches, but it was becoming difficult. But when we
started we had no real plan - just to see if we could get Solr up and
running on Lucene 3.01 and then trunk. Anything beyond that, we have not
planned for - and before that was even completed, there were emails to
java-dev about it. But we conceived nothing beyond seeing if we could
get Solr running on the latest Lucene.
From our perspective, we would have been just as happy with a branch on
my local hard drive! That would have taken longer to setup though.
--
- Mark
http://www.lucidimagination.com
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: lucene and solr trunk
Posted by Shalin Shekhar Mangar <sh...@gmail.com>.
On Tue, Mar 16, 2010 at 3:44 PM, Mark Miller <ma...@gmail.com> wrote:
> On 03/16/2010 03:43 AM, Simon Willnauer wrote:
>
>>
>> One more thing which I wonder about even more is that this whole
>> merging happens so quickly for reasons I don't see right now. I don't
>> want to keep anybody from making progress but it appears like a rush
>> to me.
>>
>>
>
> Meh - I think your just plain wrong about this. Anyone can work as fast as
> they want on anything. Nothing has happened faster than the community wants
> yet. Your too concerned. This is called discussion. Nothing has happened. In
> my opinion, the whole freak out of what goes where in svn was so over blown
> - its so easy to move this stuff around at the drop of a hat. That's why it
> was suggested we put a branch there and no one saw anything wrong it with
> for the moment - everyone said, well we can just easily move it if someone
> has an issue - which we did. Didn't expect the freak out though. Frankly, we
> were just seeking a branch really, and didn't care where it went.
>
> Some of us are anxious to do some work - some of us are anxious to merge
> some code - no one is forcing this stuff on the others at a rapid pace -
> everyone gets there say as always. This is why we wanted a branch we could
> committ what we wanted to. SVN locations make starting the merge of code
> easier. They are easy to change. This is not like rushing index format
> changes. Its src code location - it can be moved at the drop of the hat. The
> sooner we resolve what we are going to do, the sooner we can start getting
> more work done that we hoped to get down with this merge. This thread starts
> that discussion. You can't start a discussion to early. Perhaps it leads to
> another discussion first, but their is no such thing as rushing the start of
> discussion. It doesn't say "figure it out by tomorrow, cause we are doing
> this tomorrow. " It doesn't say, figure this out by next week, because we
> are doing this next week. It says lets discuss where this is going to go.
>
> I think some people just need to relax, and discuss what they would like to
> see and worry less about how fast others are working. Fast work is good. It
> means more work. Nothing is going to happen until the community figures
> things out.
>
>
> BTW: I still have the impression that if I don't follow IRC constantly
>> I'm missing important things.
>>
>>
> That's your impression then. Follow IRC if you want. People talk all over
> the places about Lucen/Solr - many times in places you can't follow - if it
> didn't happen on the list, it didn't happen. Michael Busch follows up
> saying, "people say it was discussed thoroughly on IRC" - so what? It
> doesn't count as a valid point of reference - I haven't seen that, but you
> can just tell someone that says that so - they owe you an explanation.
>
>
Wow, you guys are moving fast! Thats a good thing.
IRC is fine if you want to discuss something quickly. But it has its
limitations. For example, I cannot follow IRC most of the times because I'm
in a different time zone. But I don't want to stop anyone either. In fact, I
can't do that. Nobody can.
All I want to say is that once discussions have happened and a plan agreed
upon, it may be a good idea to let solr-dev/java-dev know the plan. In this
case I didn't know a new branch was created until I saw was a commit
notification and then Yonik's email.
--
Regards,
Shalin Shekhar Mangar.
Re: lucene and solr trunk
Posted by Mark Miller <ma...@gmail.com>.
On 03/16/2010 03:43 AM, Simon Willnauer wrote:
>
> One more thing which I wonder about even more is that this whole
> merging happens so quickly for reasons I don't see right now. I don't
> want to keep anybody from making progress but it appears like a rush
> to me.
>
Meh - I think your just plain wrong about this. Anyone can work as fast
as they want on anything. Nothing has happened faster than the community
wants yet. Your too concerned. This is called discussion. Nothing has
happened. In my opinion, the whole freak out of what goes where in svn
was so over blown - its so easy to move this stuff around at the drop of
a hat. That's why it was suggested we put a branch there and no one saw
anything wrong it with for the moment - everyone said, well we can just
easily move it if someone has an issue - which we did. Didn't expect the
freak out though. Frankly, we were just seeking a branch really, and
didn't care where it went.
Some of us are anxious to do some work - some of us are anxious to merge
some code - no one is forcing this stuff on the others at a rapid pace -
everyone gets there say as always. This is why we wanted a branch we
could committ what we wanted to. SVN locations make starting the merge
of code easier. They are easy to change. This is not like rushing index
format changes. Its src code location - it can be moved at the drop of
the hat. The sooner we resolve what we are going to do, the sooner we
can start getting more work done that we hoped to get down with this
merge. This thread starts that discussion. You can't start a discussion
to early. Perhaps it leads to another discussion first, but their is no
such thing as rushing the start of discussion. It doesn't say "figure it
out by tomorrow, cause we are doing this tomorrow. " It doesn't say,
figure this out by next week, because we are doing this next week. It
says lets discuss where this is going to go.
I think some people just need to relax, and discuss what they would like
to see and worry less about how fast others are working. Fast work is
good. It means more work. Nothing is going to happen until the community
figures things out.
> BTW: I still have the impression that if I don't follow IRC constantly
> I'm missing important things.
>
That's your impression then. Follow IRC if you want. People talk all
over the places about Lucen/Solr - many times in places you can't follow
- if it didn't happen on the list, it didn't happen. Michael Busch
follows up saying, "people say it was discussed thoroughly on IRC" - so
what? It doesn't count as a valid point of reference - I haven't seen
that, but you can just tell someone that says that so - they owe you an
explanation.
--
- Mark
http://www.lucidimagination.com
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: lucene and solr trunk
Posted by Robert Muir <rc...@gmail.com>.
On Tue, Mar 16, 2010 at 3:43 AM, Simon Willnauer
<si...@googlemail.com> wrote:
> One more thing which I wonder about even more is that this whole
> merging happens so quickly for reasons I don't see right now. I don't
> want to keep anybody from making progress but it appears like a rush
> to me.
By the way, the serious changes we applied to the branch, most of them
have been sitting in JIRA over 3 months not doing much: SOLR-1659
if you follow the linked issues, you can see all the stuff that got
put in the branch... the branch was helpful for me, as I could help
Mark with the "ton of little things", like TokenStreams embedded
inside JSP files :)
As its just a branch, if you want to go look at those patches
(especially anything I did) and provide technical feedback, that would
be great!
But I think its a mistake to say things are rushed when the work has
been done for months.
--
Robert Muir
rcmuir@gmail.com
Re: lucene and solr trunk
Posted by Simon Willnauer <si...@googlemail.com>.
On Tue, Mar 16, 2010 at 8:18 AM, Uwe Schindler <uw...@thetaphi.de> wrote:
> Hi all,
>
> I don't want to be against all other developers that voted +1 for the SVN "merge", but I am not happy with it. Most importantly for the reasons Hoss mentioned:
>
>> : prime-time as the new solr trunk! Lucene and Solr need to move to a
>> : common trunk for a host of reasons, including single patches that can
>> : cover both, shared tags and branches, and shared test code w/o a test
>> : jar.
>>
>> Without a clearer picture of how people envision development "overhead"
>> working as we move forward, it's really hard to understand how any of
>> these ideas make sense...
>> 1) how should hte automated build process(es) work?
>> 2) how are we going to do branching/tagging for releases?
>> particularly
>> in situations where one product is ready for a rlease and hte other
>> isn't?
>> 3) how are we going to deal with mino bug fix release tagging?
>> 4) should it be possible for people to check out Lucene-Java w/o
>> checking out Solr?
>
> That are important questions and not simply to solve!
>
>> (i suspect a whole lot of people who only care about the core library
>> are
>> going to really adamantly not want to have to check out all of Solr
>> just
>> to work on the core)
>
> Exactly! The Solr checkout is really huge because of thousands of JAR files and so on. The badest thing we could do would be to merge all those JARs into one general lib folder or like so. Please do not! Lucene-core should stay a lib without any external deps.
>
>> : Both projects move to a new trunk:
>> : /something/trunk/java, /something/trunk/solr
>
> This would be the only optinon we have. This new folder could simply contain two dirs below and a build.xml in the top level that delegates and builds first lucene, then solr. But you can do this also with separate checkouts and a simple script downloaded from the wiki.
>
> The problems of this approach far overweigh the positive side:
>
> In the original vote, we said, Lucene can release without Solr:
> Releasing (I was the last release mangaer) contains things like creating branches and tags. In SVN, if you create a branch, you copy everything from under trunk (or another branch) to a new folder below branches (for tags under tags). "tags" on most SVN servers has an additional limittation, that it is not possible to change anything under "tags" except copying.
>
> If we have those combined trunk folder and Lucene wants to release and creates a branch/tag. Solr is enforced to do this too. OK, you could say, we just branch the folder lucene and let solr where it is. But that would be a against conventions and the branch checkout could not life alone.
>
> I just repeat: we wanted to merge devs and not codebase! And merging devs is a "code change" clearly.
>
> And Lucene is on Java 1.5 and should be compiled with an 1.5 compiler, where Solr seems to be on 1.6 since yesterday? (Yonik added something to common-build.xml). On my development system I have no Java 1.6 installed at all as default build, I ever use Java 1.5 for building Lucene. If we merge that and have both on different JVMs the same problems like with 1.4/1.5 start. Developers use 1.6 methods because their compiler does not warn them. So everybody working on Lucene should at least have Java 1.5 compiler and try to compile his changes before committing. I do this (as I use 1.5 for developing), 1.6 on some of our servers.
>
> So: If merge, keep both on Java 1.5 !!!
>
>> by gut says something like this will more the most sense, assuming
>> "/something/trunk" == "/java/trunk" and "java" actually means "core"
>> ...
>
> And that is how it looks currently and I am fine with it!
>
>> ie: this discussion should really be part and parcel with how contribs
>> should be reorged.
>
> That is exactly what should be done. Not now simply copy the folders somewhere for some "development simplification" that not really is one and opens more problems!
>
> I propose another idea for now until the "module" decision is [DISCUSS]ed and [VOTE]d:
>
> Lets create a new project folder with trunk and branches for combined trunk development in SVN (this can be later the folder for the module development). This folder simply contains a delegating build.xml (delegating the common tasks like build and test and so on to solr and trunk).The folder simply uses svn:external SVN props to link current solr and lucene trunk as subfolders. So developers that want to work on both can simply checkout this folder and SVN will resolve the externals. As this is trunk development, the externals will be without rev numbers and relative for the http(s) problem (SVN 1.5+ required).
+1 - as I recall correctly that is what uwe and I proposed initially
on IRC when solr got copied initially. This makes a lot of sense as it
does not break anybodies checkouts and enables all "Solcene"
developers to move on. From a Lucene point of view Lucene should not
see any Solr below its root as we do not have dependencies on it,
letting them live side by side seems to be the way to go as uwe says.
One more thing which I wonder about even more is that this whole
merging happens so quickly for reasons I don't see right now. I don't
want to keep anybody from making progress but it appears like a rush
to me. Committers, start copying stuff around without discussion or
having a jira issue (sry mark :) - not blaming you personally),
discussions on the list are extremely short living and several people
seem to be rushed somehow.
I can understand the moving forward is tempting but based on all this
discussion during the "vote" could we move a little slower and little
more relaxed to figure out the right solutions.
If my impression should be wrong or if I miss something please ignore
the last paragraph.
BTW: I still have the impression that if I don't follow IRC constantly
I'm missing important things.
simon
>
> For testing flex, we create a branch of this folder, still pointing to solr-trunk, but flex branch in Lucene.
>
> One task of the main build.xml would be to copy all produced JAR files of Lucene into the correct build folder in Solr.
>
> I hope that you all understand me, but I am against merging trunks (for now) until we have a clear module decision.
>
> Uwe
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
RE: lucene and solr trunk
Posted by Uwe Schindler <uw...@thetaphi.de>.
Hi all,
I don't want to be against all other developers that voted +1 for the SVN "merge", but I am not happy with it. Most importantly for the reasons Hoss mentioned:
> : prime-time as the new solr trunk! Lucene and Solr need to move to a
> : common trunk for a host of reasons, including single patches that can
> : cover both, shared tags and branches, and shared test code w/o a test
> : jar.
>
> Without a clearer picture of how people envision development "overhead"
> working as we move forward, it's really hard to understand how any of
> these ideas make sense...
> 1) how should hte automated build process(es) work?
> 2) how are we going to do branching/tagging for releases?
> particularly
> in situations where one product is ready for a rlease and hte other
> isn't?
> 3) how are we going to deal with mino bug fix release tagging?
> 4) should it be possible for people to check out Lucene-Java w/o
> checking out Solr?
That are important questions and not simply to solve!
> (i suspect a whole lot of people who only care about the core library
> are
> going to really adamantly not want to have to check out all of Solr
> just
> to work on the core)
Exactly! The Solr checkout is really huge because of thousands of JAR files and so on. The badest thing we could do would be to merge all those JARs into one general lib folder or like so. Please do not! Lucene-core should stay a lib without any external deps.
> : Both projects move to a new trunk:
> : /something/trunk/java, /something/trunk/solr
This would be the only optinon we have. This new folder could simply contain two dirs below and a build.xml in the top level that delegates and builds first lucene, then solr. But you can do this also with separate checkouts and a simple script downloaded from the wiki.
The problems of this approach far overweigh the positive side:
In the original vote, we said, Lucene can release without Solr:
Releasing (I was the last release mangaer) contains things like creating branches and tags. In SVN, if you create a branch, you copy everything from under trunk (or another branch) to a new folder below branches (for tags under tags). "tags" on most SVN servers has an additional limittation, that it is not possible to change anything under "tags" except copying.
If we have those combined trunk folder and Lucene wants to release and creates a branch/tag. Solr is enforced to do this too. OK, you could say, we just branch the folder lucene and let solr where it is. But that would be a against conventions and the branch checkout could not life alone.
I just repeat: we wanted to merge devs and not codebase! And merging devs is a "code change" clearly.
And Lucene is on Java 1.5 and should be compiled with an 1.5 compiler, where Solr seems to be on 1.6 since yesterday? (Yonik added something to common-build.xml). On my development system I have no Java 1.6 installed at all as default build, I ever use Java 1.5 for building Lucene. If we merge that and have both on different JVMs the same problems like with 1.4/1.5 start. Developers use 1.6 methods because their compiler does not warn them. So everybody working on Lucene should at least have Java 1.5 compiler and try to compile his changes before committing. I do this (as I use 1.5 for developing), 1.6 on some of our servers.
So: If merge, keep both on Java 1.5 !!!
> by gut says something like this will more the most sense, assuming
> "/something/trunk" == "/java/trunk" and "java" actually means "core"
> ...
And that is how it looks currently and I am fine with it!
> ie: this discussion should really be part and parcel with how contribs
> should be reorged.
That is exactly what should be done. Not now simply copy the folders somewhere for some "development simplification" that not really is one and opens more problems!
I propose another idea for now until the "module" decision is [DISCUSS]ed and [VOTE]d:
Lets create a new project folder with trunk and branches for combined trunk development in SVN (this can be later the folder for the module development). This folder simply contains a delegating build.xml (delegating the common tasks like build and test and so on to solr and trunk).The folder simply uses svn:external SVN props to link current solr and lucene trunk as subfolders. So developers that want to work on both can simply checkout this folder and SVN will resolve the externals. As this is trunk development, the externals will be without rev numbers and relative for the http(s) problem (SVN 1.5+ required).
For testing flex, we create a branch of this folder, still pointing to solr-trunk, but flex branch in Lucene.
One task of the main build.xml would be to copy all produced JAR files of Lucene into the correct build folder in Solr.
I hope that you all understand me, but I am against merging trunks (for now) until we have a clear module decision.
Uwe
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: lucene and solr trunk
Posted by Chris Hostetter <ho...@fucit.org>.
: prime-time as the new solr trunk! Lucene and Solr need to move to a
: common trunk for a host of reasons, including single patches that can
: cover both, shared tags and branches, and shared test code w/o a test
: jar.
Without a clearer picture of how people envision development "overhead"
working as we move forward, it's really hard to understand how any of
these ideas make sense...
1) how should hte automated build process(es) work?
2) how are we going to do branching/tagging for releases? particularly
in situations where one product is ready for a rlease and hte other isn't?
3) how are we going to deal with mino bug fix release tagging?
4) should it be possible for people to check out Lucene-Java w/o
checking out Solr?
(i suspect a whole lot of people who only care about the core library are
going to really adamantly not want to have to check out all of Solr just
to work on the core)
: Both projects move to a new trunk:
: /something/trunk/java, /something/trunk/solr
by gut says something like this will more the most sense, assuming
"/something/trunk" == "/java/trunk" and "java" actually means "core" ...
ie: this discussion should really be part and parcel with how contribs
should be reorged.
-Hoss
Re: lucene and solr trunk
Posted by Chris Hostetter <ho...@fucit.org>.
: prime-time as the new solr trunk! Lucene and Solr need to move to a
: common trunk for a host of reasons, including single patches that can
: cover both, shared tags and branches, and shared test code w/o a test
: jar.
Without a clearer picture of how people envision development "overhead"
working as we move forward, it's really hard to understand how any of
these ideas make sense...
1) how should hte automated build process(es) work?
2) how are we going to do branching/tagging for releases? particularly
in situations where one product is ready for a rlease and hte other isn't?
3) how are we going to deal with mino bug fix release tagging?
4) should it be possible for people to check out Lucene-Java w/o
checking out Solr?
(i suspect a whole lot of people who only care about the core library are
going to really adamantly not want to have to check out all of Solr just
to work on the core)
: Both projects move to a new trunk:
: /something/trunk/java, /something/trunk/solr
by gut says something like this will more the most sense, assuming
"/something/trunk" == "/java/trunk" and "java" actually means "core" ...
ie: this discussion should really be part and parcel with how contribs
should be reorged.
-Hoss
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: lucene and solr trunk
Posted by Yonik Seeley <yo...@apache.org>.
On Tue, Mar 16, 2010 at 5:42 AM, Michael McCandless
<lu...@mikemccandless.com> wrote:
> I think it like the 1st option best (lucene moves as subdir to solr's
> current trunk SVN path), but I don't feel strongly.
>
> This'd mean one could simply checkout lucene alone and do everything
> you can do today.
>
> But if you check out solr, you also get a full checkout of lucene, and
> solr's build.xml will go and build lucene, copy over its jars to its
> lib folder, and then do everything it currently does.
>
> I think?
>
> This small step is not much change over what we have today -- the code
> simply moves, unchanged, except for some fixes to solr's build.xml to
> go and build its lucene subdir first.
Huh - I was leaning more toward putting solr under lucene because I
thought that might be more acceptable to the lucene folks (actually,
now lucene/solr folks) than vice-versa.
But your points make perfect sense.
> The bigger stuff, ideas on modules like renaming contrib->modules,
> consolidating all analyzers, queries, queryparsers, highlighters, all
> comes later.
+1
-Yonik
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: lucene and solr trunk
Posted by Michael McCandless <lu...@mikemccandless.com>.
I think it like the 1st option best (lucene moves as subdir to solr's
current trunk SVN path), but I don't feel strongly.
This'd mean one could simply checkout lucene alone and do everything
you can do today.
But if you check out solr, you also get a full checkout of lucene, and
solr's build.xml will go and build lucene, copy over its jars to its
lib folder, and then do everything it currently does.
I think?
This small step is not much change over what we have today -- the code
simply moves, unchanged, except for some fixes to solr's build.xml to
go and build its lucene subdir first.
The bigger stuff, ideas on modules like renaming contrib->modules,
consolidating all analyzers, queries, queryparsers, highlighters, all
comes later.
Mike
On Mon, Mar 15, 2010 at 10:28 PM, Yonik Seeley <yo...@apache.org> wrote:
> Due to a tremendous amount of work by our newly merged committer
> corps, the get-on-lucene-trunk branch (branches/solr) is ready for
> prime-time as the new solr trunk! Lucene and Solr need to move to a
> common trunk for a host of reasons, including single patches that can
> cover both, shared tags and branches, and shared test code w/o a test
> jar.
>
> The current Lucene trunk is: .../lucene/java/trunk
> The current Solr trunk is: .../lucene/solr/trunk
>
> So, we have a few options on where to put Solr's new trunk:
>
> Lucene moves to Solr's trunk:
> /solr/trunk, /solr/trunk/lucene
>
> Solr moves to Lucene's trunk:
> /java/trunk, /java/trunk/solr
>
> Both projects move to a new trunk:
> /something/trunk/java, /something/trunk/solr
>
> -Yonik
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org