lucene and solr trunk

classic Classic list List threaded Threaded
58 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: lucene and solr trunk

Shai Erera
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 <[hidden email]> wrote:
On Tue, Mar 16, 2010 at 2:53 PM, Yonik Seeley <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: lucene and solr trunk

Jake Mannix
In reply to this post by Yonik Seeley

On Tue, Mar 16, 2010 at 3:10 PM, Yonik Seeley <[hidden email]> wrote:
On Tue, Mar 16, 2010 at 6:01 PM, Jake Mannix <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: lucene and solr trunk

Michael McCandless-2
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 <[hidden email]> wrote:

>
> On Tue, Mar 16, 2010 at 3:10 PM, Yonik Seeley <[hidden email]> wrote:
>>
>> On Tue, Mar 16, 2010 at 6:01 PM, Jake Mannix <[hidden email]>
>> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: lucene and solr trunk

Michael McCandless-2
In reply to this post by Shai Erera
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 <[hidden email]> 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 <[hidden email]> wrote:
>>
>> On Tue, Mar 16, 2010 at 2:53 PM, Yonik Seeley <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: lucene and solr trunk

Michael McCandless-2
+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
<[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
>>>
>>> On Tue, Mar 16, 2010 at 2:53 PM, Yonik Seeley <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: lucene and solr trunk

Michael Busch
In reply to this post by Michael McCandless-2
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<[hidden email]>  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<[hidden email]>  wrote:
>>      
>>> On Tue, Mar 16, 2010 at 2:53 PM, Yonik Seeley<[hidden email]>  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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
>    


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: lucene and solr trunk

Michael McCandless-2
In reply to this post by Michael McCandless-2
Duh -- I meant to reply to Hoss' proposal, below:

On Tue, Mar 16, 2010 at 5:55 PM, Michael McCandless
<[hidden email]> 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
> <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
>>>>
>>>> On Tue, Mar 16, 2010 at 2:53 PM, Yonik Seeley <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: lucene and solr trunk

Wouter Heijke
In reply to this post by Michael McCandless-2
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 <[hidden email]> 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 <[hidden email]>
>> wrote:
>>>
>>> On Tue, Mar 16, 2010 at 2:53 PM, Yonik Seeley <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
>



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: lucene and solr trunk

Earwin Burrfoot
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
>>> wrote:
>>>>
>>>> On Tue, Mar 16, 2010 at 2:53 PM, Yonik Seeley <[hidden email]> 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: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>



--
Kirill Zakharenko/Кирилл Захаренко ([hidden email])
Home / Mobile: +7 (495) 683-567-4 / +7 (903) 5-888-423
ICQ: 104465785

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: lucene and solr trunk

Stefan Trcek
In reply to this post by Mark Miller-3
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: lucene and solr trunk

hossman
In reply to this post by Wouter Heijke
: 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: #lucene IRC log [was: RE: lucene and solr trunk]

Ian Holsman (Lists)
In reply to this post by hossman
+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: [hidden email]
For additional commands, e-mail: [hidden email]


  

Reply | Threaded
Open this post in threaded view
|

Re: lucene and solr trunk

Ian Holsman (Lists)
In reply to this post by hossman
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: [hidden email]
For additional commands, e-mail: [hidden email]


  

Reply | Threaded
Open this post in threaded view
|

Re: lucene and solr trunk

Earwin Burrfoot
In reply to this post by hossman
> 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 <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>



--
Kirill Zakharenko/Кирилл Захаренко ([hidden email])
Home / Mobile: +7 (495) 683-567-4 / +7 (903) 5-888-423
ICQ: 104465785

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: lucene and solr trunk

Mark Miller-3
In reply to this post by Yonik Seeley-2
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: lucene and solr trunk

Michael McCandless-2
All tests pass for me :)

Mike

On Thu, Mar 18, 2010 at 12:27 PM, Mark Miller <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: #lucene IRC log [was: RE: lucene and solr trunk]

Otis Gospodnetic-2
In reply to this post by Ian Holsman (Lists)
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 <[hidden email]>
To: [hidden email]
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: [hidden email] For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: #lucene IRC log [was: RE: lucene and solr trunk]

Marvin Humphrey
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: [hidden email]
For additional commands, e-mail: [hidden email]

123