<<<if experienced users are happy whith it it is now, then it is probably good>>>
Or maybe they've just forgotten how very painful first-time setup can be <G>... I know that once I have things set up, I try mightily to avoid ever having to do it again because it hurts each and every time...... But this is the enormous value of fresh eyes, somebody to say "Does this *have* to be this way?".... Just for yucks, I took Paolo's zipped-up files for solr and lucene and blew away my source tree, got it all fresh from the repository, applied his files and was up and running. I had one bit of ugliness that was fixed by refreshing the project after putting his .classpath and .project files in place. I'll see if I can get to doing it all again this weekend and putting it up on the Wiki. If I'm truly ambitious, I'll even see if I can get something similar for IntelliJ going, but don't hold your breath on the latter, but I'm going to try to cheat by telling IntelliJ to create projects from Eclipse configs... I was once "transferring knowledge" of a complex build system to a partner. The guy I was working with sat beside me and made me type in instructions *before* typing in any command. It kind of annoyed me at the time, but since I've come to believe that that's the *only* way to get all the steps in.... He's the same person who mentioned what I'd like to suggest as an official policy, the "three beer rule". Not *writing* code, but reading it. It went something like this: "If you can't *understand* code you've written after you've had three beers, you need to go back and simplify it when you're sober" <G>..... Best Erick On Fri, Apr 16, 2010 at 8:32 AM, hkmortensen <ko...@yahoo.com> wrote: > > I have always used relative paths in my (official) classpath file for > eclipse, I was not aware of, that any other could make sense. It is an > easy > way to ensure that everybody use the same version of the libs. I see the > problem with different IDEs. > > I dont think I volonteer, there seem to be quite many oppinions on this, > and > if experienced users are happy whith it it is now, then it is probably good > ;-) > > > > > > > Erick Erickson 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. > >>>> > >>>> > >>> > > > > > > -- > View this message in context: > http://n3.nabble.com/Eclipse-project-files-tp708987p723819.html > Sent from the Solr - Dev mailing list archive at Nabble.com. >
