struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Graham <>
Subject Re: [OT] Re: keeping Eclipse files in our repo [was Re: Package removal with new Digester]
Date Fri, 03 Dec 2004 15:14:40 GMT

--- Matt Bathje <> 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 files, no conflicting jar versions, etc.


> Matt
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message