All tests pass for me :) Mike
On Thu, Mar 18, 2010 at 12:27 PM, Mark Miller <markrmil...@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-unsubscr...@lucene.apache.org > For additional commands, e-mail: java-dev-h...@lucene.apache.org > >
