You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Mike Kienenberger <mk...@alaska.net> on 2004/12/02 22:09:01 UTC
keeping Eclipse files in our repo [was Re: Package removal with new
Digester]
Martin Cooper <mf...@gmail.com> 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: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: keeping Eclipse files in our repo [was Re: Package removal with new Digester]
Posted by Michael Rasmussen <ra...@gmail.com>.
> I am very much against keeping IDE specific files in the repository.
+1
Michael
---------------------------------------------------------------------
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]
Posted by 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]
Posted by 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
[OT] Re: keeping Eclipse files in our repo [was Re: Package removal
with new Digester]
Posted by 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: keeping Eclipse files in our repo [was Re: Package removal with new Digester]
Posted by David Graham <gr...@yahoo.com>.
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 <mp...@ntsource.com> 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 <mk...@alaska.net> wrote:
> >
> >
> >>Martin Cooper <mf...@gmail.com> 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: dev-unsubscribe@struts.apache.org
> >>For additional commands, e-mail: dev-help@struts.apache.org
> >>
> >>
> >
> >
> >
> >
> >
> > __________________________________
> > Do you Yahoo!?
> > Yahoo! Mail - Easier than ever with enhanced search. Learn more.
> > http://info.mail.yahoo.com/mail_250
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
>
>
> ---------------------------------------------------------------------
> 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
Re: keeping Eclipse files in our repo [was Re: Package removal with
new Digester]
Posted by Matt Bathje <mp...@ntsource.com>.
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 <mk...@alaska.net> wrote:
>
>
>>Martin Cooper <mf...@gmail.com> 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: dev-unsubscribe@struts.apache.org
>>For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>
>
>
>
>
> __________________________________
> Do you Yahoo!?
> Yahoo! Mail - Easier than ever with enhanced search. Learn more.
> http://info.mail.yahoo.com/mail_250
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: keeping Eclipse files in our repo [was Re: Package removal with new Digester]
Posted by David Graham <gr...@yahoo.com>.
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 <mk...@alaska.net> wrote:
> Martin Cooper <mf...@gmail.com> 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: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
__________________________________
Do you Yahoo!?
Yahoo! Mail - Easier than ever with enhanced search. Learn more.
http://info.mail.yahoo.com/mail_250
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org