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.

After struggling with acquiring all the jars needed to build Struts and
then configuring ant to use them I have decided that storing the
dependencies in cvs is the best solution.  The build references the lib
directory which is necessarily the same on all machines because it's
checked out from cvs.  My understanding is this doesn't work for Struts
because it uses non-free dependencies that can't be stored on Apache's
systems.

David

--- Matt Bathje <[EMAIL PROTECTED]> wrote:

> With eclipse at least, this limitation can be easily worked around.
> 
> Anything that uses a machine-specific path (or whatever else that may be
> 
> machine specific) is referenced to by a variable that each developer can
> 
> set on their machine. What gets committed only has references to those 
> variables, so as long as there is some documentation on what they need 
> to be set to, there is no problem. This is how we do our internal
> projects.
> 
> That being said, I'm not sure having IDE specific stuff is right for 
> something like Struts.
> 
> Matt
> 
> 
> David Graham wrote:
> > Thanks for changing the subject line so I noticed this thread again.  
> > 
> > I am very much against keeping IDE specific files in the repository. 
> Even
> > if you're using the same IDE, no two developer's environment will be
> the
> > same so paths will be wrong, etc.  This will be painful because
> checking
> > out the code will corrupt my Eclipse .project and .classpath files.
> > 
> > We will end up with many IDE files in the repository none of which
> work
> > for anyone except the last person who committed them.
> > 
> > David
> > 
> > --- Mike Kienenberger <[EMAIL PROTECTED]> wrote:
> > 
> > 
> >>Martin Cooper <[EMAIL PROTECTED]> wrote:
> >>
> >>>Other issues with keeping Eclipse files in our repo:
> >>>
> >>>1) The expectation would be that they would be kept up to date. If a
> >>>particular committer doesn't use Eclipse, I don't think it's fair to
> >>>expect them to keep Eclipse config files up to date when they make
> >>>changes elsewhere.
> >>
> >>In the cayenne project, the .classpath and .project files are stored
> in 
> >>/cayenne/contrib/ide/eclipse/.  If you want to use them, you just copy
> >>them 
> >>into your root project directory first.
> >>
> >>At least under Eclipse, these files don't change very frequently
> >>(.classpath 
> >>when project dependency changes, .project never changes.).
> >>
> >>If you don't use a particular editor, you don't need to mess with
> them. 
> >>Let 
> >>the people using that particular editor update them.  It's the same
> >>thing 
> >>that's going to happen even if the config files are not in the repo. 
> >>The 
> >>only difference is that it gives a starting point (and will generally
> be
> >>
> >>up-to-date for a particular editor if active committers are using it).
> >>
> >>-Mike
> >>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: [EMAIL PROTECTED]
> >>For additional commands, e-mail: [EMAIL PROTECTED]
> >>
> >>
> > 
> > 
> > 
> > 
> >             
> > __________________________________ 
> > Do you Yahoo!? 
> > Yahoo! Mail - Easier than ever with enhanced search. Learn more.
> > http://info.mail.yahoo.com/mail_250
> > 
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> ---------------------------------------------------------------------
> 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]

Reply via email to