lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Miller <>
Subject Re: lucene and solr trunk
Date Thu, 18 Mar 2010 17:27:31 GMT
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

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 =
>>    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:
For additional commands, e-mail:

View raw message