On Fri, Mar 25, 2011 at 10:45 AM, Grant Ingersoll <gsing...@apache.org> wrote:
> I do think we need standalone artifacts. So, I suppose if we do that, then > we can't just svn export, b/c we would need to separate dev tools per > project. But, then again, why can't we have: > /dev-tools/ > /lucene/dev-tools > /solr/dev-tools > > The top level just creates IDE that includes the lower ones, but the lower > ones can each be standalone. (This goes for the Maven stuff too). > > I realize, of course, this is work, so my suggestion would be we do 3.1 w/ it > included as is and then fix in the next release. > I would be against this. currently to fix eclipse i just copy the .classpath file to /dev-tools/eclipse/dot.classpath and commit. This makes it significantly harder. Additionally I don't see how this could possibly work: a "standalone" solr would use lucene jar files since it doesnt include the lucene source. Because of this, a "top-level" dev-tools eclipse configuration would not be the composition of lucene+solr, instead it would be a totally different thing. So I don't think this is useful: dev-tools is for developers, and developers are all using the big /trunk checkout, so we don't need dev-tools at a lower level, for no good reason. Honestly I could care less about making it easy for someone to configure lucene or solr by itself in their IDE. I did the eclipse work (for example) to make it easier for people to contribute to lucene/solr, I could care less about making it easier for people to configure their "own private copies" of lucene or solr easier, and I'm definitely not going to let it make it *harder* on us to support contributions (the top-level /dev-tools). This is becoming a slippery slope fast... Uwe's perspective is starting to become much more attractive. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
