: versions of HDFS. So the direction there is the opposite of what's been : proposed here: introducing layered project dependencies rather than reducing : them. It's too soon to say how well that split will work, just as I think it's : difficult to guess how well merging Lucene and Solr will fare. From : experience, we know the downsides of Lucene and Solr being split, now we may : have the opportunity to learn the downsides of being merged!
I don't actually think we really have any clue about the benefits/downsides of being "split" .. as a sub-project some people seem to expect that Solr is in lock step with Lucene-Java, but if Solr became a TLP I think that impression would be reduced. All of the same goals about wanting to have less duplicated code, and a build system that's more closely tied with the Lucene trunk would be just as possible if Solr were a TLP -- it's just a matter of modifying Solr's processes, refactoring/promoting existing code and encouraging Solr developers to contribute "common" code to Lucene-Java as well (and to get Solr committers to "reject" contributions that really belong in Lucene-Java) -- all of which just requires more effort on everyones part, but not neccessarily a change in process or project structure. The increased effort is likely to be the same regardless of wether Solr is a subproject, or it's own TLP, or absorbed into Lucene-Java. -Hoss
