+1 for this structure and this set of steps. Otis
----- Original Message ---- > From: Chris Hostetter <hossman_luc...@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
