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
