This content has been marked as final.
Show 11 replies
-
1. Re: Update the relevant .classpath files
adrian.brock Feb 29, 2008 8:48 AM (in response to alesj)"alesj" wrote:
I'm always in favor of not keeping things around that can be generated.
And we're doing that with javacc, so why the change-of-heart here? ;-)
Because eclipse is a real pain when you have to regenerate things
and (pull the rug out from underneath it).
It's incremental compiler gets well confused and trying to make it do
a full rebuild doesn't always fix it (it caches stuff it shouldn't - even across reboots).
A couple of weeks ago, I ended up doing a full recreate of my MC project
because eclipse decided it couldn't find java.lang.Object and I couldn't
find a way to fix it. ;-)
This issue isn't so bad with the small MC codebase,
but with the JBossAS code tree, I can loose literally hours when it decides
it isn't going to play nice with an svn update. :-( -
2. Re: Update the relevant .classpath files
alesj Feb 29, 2008 8:58 AM (in response to alesj)OK, I definitely don't want to see you loosing too much time doing this stuff :-), but I fail to see how this is relevant.
e.g. you get your updated .classpath from svn
or you get updated pom from svn, close Eclispe (so you're not pulling the rug), run the maven-ide generator, open Eclipse -
3. Re: Update the relevant .classpath files
alrubinger Feb 29, 2008 10:37 AM (in response to alesj)"alesj" wrote:
I'm always in favor of not keeping things around that can be generated.
+1.
For Eclipse, this may be done:mvn eclipse:clean; mvn eclipse:eclipse
...and then set the Variable "M2_REPO" within the IDE to point to your Maven2 Repo (~/.m2/repository by default in *nix).
S,
ALR -
4. Re: Update the relevant .classpath files
adrian.brock Feb 29, 2008 11:19 AM (in response to alesj)"alesj" wrote:
OK, I definitely don't want to see you loosing too much time doing this stuff :-), but I fail to see how this is relevant.
e.g. you get your updated .classpath from svn
or you get updated pom from svn, close Eclispe (so you're not pulling the rug), run the maven-ide generator, open Eclipse
Because, I get an error when I load eclipse when it can't find the method/class/jar.
I fix it, and then I've might have to fight eclipse's incremental compiler
because I missed a step in some many stage svn update procedure.
We've had this discussion before. What I really want is maven to automatically
run mvn eclipse:eclipse when it detects the .classpath is earlier than
the pom.xml. That way any developer modifying the poms will
automatically check in updated .classpath files and it doesn't become
an "infinite stage" process to get a working development environment
after an svn update as I try to figure out what changed
what I need/forgot to rerun and what eclipse thinks is going on. -
5. Re: Update the relevant .classpath files
adrian.brock Feb 29, 2008 11:25 AM (in response to alesj)"ALRubinger" wrote:
"alesj" wrote:
I'm always in favor of not keeping things around that can be generated.
+1.
For Eclipse, this may be done:
It's not a vote. Either make a logical argument or go join some Apache project
where you can make these usless comments to your hearts content. :-) -
6. Re: Update the relevant .classpath files
alrubinger Feb 29, 2008 11:34 AM (in response to alesj)"adrian@jboss.org wrote:
It's not a vote. Either make a logical argument or go join some Apache project where you can make these usless comments to your hearts content. :-)
We get it, Adrian, you're intimidating.
I'll spell it out, then.
Adding .classpath and .project files to the repo might seem like a convenience to users of the Eclipse IDE, but actuality what we're doing here is introducing elements that are unbound to actual changes in the POM, and may be misleading.
By guaranteeing a build that will function from the command-line only, we add a fail-fast; compilation WILL fail in IDEs. It becomes the responsibility of the developer to add extensions to make it work in their preferred environment. And with the maven commands I've illustrated, it's incredibly simply to do so with Eclipse. We can even bind it to the build lifecycle in an Eclipse profile if we'd like.
Generated code in a central repo is redundant and easily outdated. And users of IntelliJ (like Ales) shouldn't have to worry about the CP of Eclipse users.
S,
ALR -
7. Re: Update the relevant .classpath files
adrian.brock Feb 29, 2008 12:07 PM (in response to alesj)"ALRubinger" wrote:
"adrian@jboss.org wrote:
It's not a vote. Either make a logical argument or go join some Apache project where you can make these usless comments to your hearts content. :-)
We get it, Adrian, you're intimidating.
No just don't have time to read drivel :-)
I'll spell it out, then.
Adding .classpath and .project files to the repo might seem like a convenience to users of the Eclipse IDE, but actuality what we're doing here is introducing elements that are unbound to actual changes in the POM, and may be misleading.
By guaranteeing a build that will function from the command-line only, we add a fail-fast; compilation WILL fail in IDEs. It becomes the responsibility of the developer to add extensions to make it work in their preferred environment. And with the maven commands I've illustrated, it's incredibly simply to do so with Eclipse. We can even bind it to the build lifecycle in an Eclipse profile if we'd like.
Generated code in a central repo is redundant and easily outdated. And users of IntelliJ (like Ales) shouldn't have to worry about the CP of Eclipse users.
S,
ALR
We'll continue to disagree.
Technical
* It's called an I(ntegrated)DE for a reason
* "Baby sitting" builds and tools is not what I want to do
* Remembering and performing recipes of many tool procedures is not productive
(it's a good job I know how to program bash, but that's just a hack around the problem :-)
* Eclipse is what I use, we can do the same for Intellij (actually I don't use eclipse as much
as I could because sometimes it is just too painful)
* Checking in the eclipse files in svn makes little difference in practice
unless everybody updates them you have to run mvn eclipse:eclipse anyway.
It's just you have N updaters running it instead of one committer.
Philosophy
* Redundancy is only a problem when it leads to error or reduced performance
* Redundancy to improve performance and reduce error is a good thing
* Claiming that it can lead to error in checking .classpath files because the real
problem is in maven/eclipse not being able to understand each other
mistates where the problem lies.
* When it annoys me enough, I'll fix the real problem, in the meantime
it's workarounds and lots of hair pulling :-) -
8. Re: Update the relevant .classpath files
alrubinger Feb 29, 2008 12:43 PM (in response to alesj)"adrian@jboss.org" wrote:
We'll continue to disagree.
I'm OK with that. :) But I would like to come to a conclusion here (one way or the other) as I'm sometimes unsure how to best maintain my projects' builds."adrian@jboss.org" wrote:
It's called an I(ntegrated)DE for a reason
...so we should account for Eclipse's shortcomings in the repo?"adrian@jboss.org" wrote:
Remembering and performing recipes of many tool procedures is not productive
You're going to have to do it anyway whenever you make changes to the dependencies."adrian@jboss.org" wrote:
Redundancy is only a problem when it leads to error or reduced performance
This is the root of my concern; an Eclipse user with an outdated classpath."adrian@jboss.org" wrote:
Checking in the eclipse files in svn makes little difference in practice unless everybody updates them you have to run mvn eclipse:eclipse anyway.
Exactly! I'm banking on "not everyone updating", meaning you'd have to run eclipse:eclipse anyway. The difference is one of precedent; by not committing .classpath you EXPECT to have to make this step, not wondering why the build is broken.
S,
ALR -
9. Re: Update the relevant .classpath files
adrian.brock Feb 29, 2008 12:58 PM (in response to alesj)"ALRubinger" wrote:
"adrian@jboss.org" wrote:
Remembering and performing recipes of many tool procedures is not productive
You're going to have to do it anyway whenever you make changes to the dependencies.
Not if there's a mojo defined in the pom that says, aha the pom is newer
than the .classpath file, re-run eclipse:eclipse automagically."adrian@jboss.org" wrote:
Redundancy is only a problem when it leads to error or reduced performance
This is the root of my concern; an Eclipse user with an outdated classpath.
How is it different to what you suggest (no .classpath file or an old
one they generated before doing the svn update?)"adrian@jboss.org" wrote:
Checking in the eclipse files in svn makes little difference in practice unless everybody updates them you have to run mvn eclipse:eclipse anyway.
Exactly! I'm banking on "not everyone updating", meaning you'd have to run eclipse:eclipse anyway. The difference is one of precedent; by not committing .classpath you EXPECT to have to make this step, not wondering why the build is broken.
S,
ALR
I'm simply asking;
* NOT to have to remember.
* NOT to have to do it as a seperate step
Either the committer does it when they build and test before committing,
or if they are not diligent, I do it when I rebuild after an svn update.
(When I say committer or I, that means that running a Maven compile does it.)
Of course the real fix is to replace eclipse's java project bundle
with an extended one that runs off the pom.xml instead of .classpath ;-) -
10. Re: Update the relevant .classpath files
alrubinger Feb 29, 2008 2:20 PM (in response to alesj)"adrian@jboss.org wrote:
How is it different to what you suggest (no .classpath file or an old one they generated before doing the svn update?)
Fail-fast. No .classpath is very obviously wrong in Eclipse. An incorrect .classpath might pose as correct (pointing to wrong versions, perhaps).
Though I still disagree with storing gen'd files in SCM, I can live with the addition of a Mojo/Plugin to autorun eclipse:eclipse.
At the end of the day, this is developer preference, we're debating the architecture of .classpath here. :)"adrian@jboss.org" wrote:
Of course the real fix is to replace eclipse's java project bundle with an extended one that runs off the pom.xml instead of .classpath ;-)
Max/Culpepper/Stryker...get on it. :D
S,
ALR -
11. Re: Update the relevant .classpath files
alrubinger Feb 29, 2008 2:22 PM (in response to alesj)Indirectly-related, but often helpful is the m2eclipse Plugin:
http://m2eclipse.codehaus.org/
...which I use to not worry about .classpath at all. :)
S,
ALR