Hmmm, now that I look at the rest of the thread (sorry, I just skim things at work) I see you already did provide the zips.
I wonder if it would suffice to put them on the Wiki and point to them..... er...@ishouldreadmorethoroughly.com On Thu, Apr 15, 2010 at 7:48 PM, Erick Erickson <erickerick...@gmail.com>wrote: > Well, there certainly *can* be absolute paths, it depends > on whether all your jars are relative to the checked-out > project or whether you had to go exploring your machine. > > But that's a nit. I agree it's certainly possible to carefully > construct the necessary files so that all paths are relative, > and include all the relevant jars located at those relative > path locations. > > Are you volunteering? If so, feel free to create a JIRA > and attach any patches, I'm sure one of the committers will > be happy to make it happen, assuming they approve... > > Erick > > But you're right > > > On Thu, Apr 15, 2010 at 5:40 PM, Paolo Castagna < > castagna.li...@googlemail.com> wrote: > >> Erick Erickson wrote: >> >>> <<<Why are classpath files generally not included in open source >>> projects?>>> >>> >>> because they're always wrong <G>... >>> >> >> It is possible to get it right and when it happens users will have a >> much better experience when they checkout the sources of a project. >> >> Just a few examples of things I use: >> >> - https://jena.svn.sourceforge.net/svnroot/jena/TDB/trunk/.classpath >> - https://jena.svn.sourceforge.net/svnroot/jena/ARQ/trunk/.classpath >> - http://svn.apache.org/repos/asf/hadoop/common/trunk/build.xml >> >> With Maven and/or Ant+Ivy it's possible to generate Eclipse .classpath >> and .project files automatically from your pom.xml file or from your >> ivy.xml (Hadoop does that). >> >> >> If I put mine in c:\apache, and you put yours in c:\trunk, our classpath >>> files will reflect that. And I *really* don't want to update the project >>> and >>> get my classpath file overwritten with yours. >>> >>> Not to mention that I *actually* work on a mac, where Ant has been >>> installed in /usr and....... >>> >> >> The examples above work on Linux, Windows and should work on Mac OS X as >> well, there are no absolute paths in the .classpath or .project files. >> >> >> Not to mention other libraries. And what about plugins? >>> >>> That said, one *can* include a sample classpath and, perhaps, project >>> file, that can be copied to "the correct place" and changed to reflect >>> the >>> local setup as has been done on the Wiki, see: >>> http://wiki.apache.org/lucene-java/HowToContribute >>> >> >> Eclipse .classpath and .project files can be checked into the source >> code repository or they can be generated as part of the building system. >> >> I'd love to have the same good experience with Lucene and Solr... I am >> still having problems trying to configure Eclipse to run Solr tests (and >> yes, I've changed the current directory... but I still have problems). >> >> Paolo >> >> >> Best >>> Erick >>> >>> On Thu, Apr 15, 2010 at 5:04 PM, hkmortensen <ko...@yahoo.com> wrote: >>> >>> I spend about two days last week to import lucene and solr in eclipse. I >>>> would not call it easy at all. I took the test sources away completely >>>> (from >>>> the source path). >>>> >>>> I would like to help putting some useable project files for eclipse >>>> together >>>> (including the test files ;-) ). >>>> >>>> Why are classpath files generally not included in open source projects? >>>> Would they do any harm? I realise when you get experienced with the >>>> software >>>> you want to make it slim to make text search faster. But for new people >>>> in >>>> a project it would be a lot nicer, I think. >>>> >>>> Is there any way of distribute work on the solr project? I would not >>>> like >>>> to >>>> do a lot of effort to adapt to eclipse if somebody else does it the same >>>> time >>>> >>>> >>>> -- >>>> View this message in context: >>>> http://n3.nabble.com/Eclipse-project-files-tp708987p722342.html >>>> Sent from the Solr - Dev mailing list archive at Nabble.com. >>>> >>>> >>> >
