[OT] Re: keeping Eclipse files in our repo [was Re: Package removal with new Digester]

[Matt Bathje <mp...@ntsource.com>]

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.

Are you worried that people won't read the documentation? Or that 
multiple variables may point to the same resource?

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

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.

Matt

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: [OT] Re: keeping Eclipse files in our repo [was Re: Package removal with new Digester]

[Matt Bathje <mp...@ntsource.com>]

David Graham wrote:
> --- Matt Bathje <mp...@ntsource.com> wrote:
>>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 :-).
> 

Fair enough :)


Thanks,
Matt

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: [OT] Re: keeping Eclipse files in our repo [was Re: Package removal with new Digester]

[David Graham <gr...@yahoo.com>]

--- Matt Bathje <mp...@ntsource.com> 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: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
> 
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org