--- Matt Bathje <[EMAIL PROTECTED]> wrote: > David Graham wrote: > > Eclipse classpath variables don't solve the issue because each > developer > > may be using different variable names. Further, the name of the jar > file > > may be different (ie. have version number in it). In my experience, > > forcing developers to use the "one true setup" is a recipe for > disaster. > > > > This is off topic now so I'm sorry to continue it, but I'm not sure I > get your point here. > > Why would a developer use different variable names? If > .classpath/.project for eclipse were included, there must be > documentation saying "you must setup VARIABLEX to point to RESOURCEX" > and so forth.
IMO, dictating the one true way to setup your IDE (including variable names) is a bad idea. > > Are you worried that people won't read the documentation? Or that > multiple variables may point to the same resource? I would rather write code than reading a bunch of documentation telling me I setup my IDE incorrectly :-). > > I also don't get why it matters that the name of the jar files may be > different. That is the point of the variables. If I have variablex > pointing to: > > c:/matt/struts/libs/resource1.2.3.jar > > and you have variablex pointing to: > > c:/david/struts/libs/resourceABC.jar For some reason I was thinking you would setup a variable to the directory the jar was in and then extend the variable with the jar's name. But you would just point the variable to the full jar path as in your example. > > it doesn't matter as far as I know. One of the developers here compiled > his own copy of junit with some specialized stuff in it that I didn't > know about for a long time, mostly because we use variables to point to > the junit jar :) > > I do think there would be problems with people forgetting to update a > variable to point to the proper version of a resource...but your > arguments aren't making sense to me. This problem is completely avoided if you put the jars in a lib directory in your project's cvs/svn repo. No classpath variables, no ant build.properties files, no conflicting jar versions, etc. David > > Matt > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]