11 Replies Latest reply on Feb 29, 2008 2:22 PM by alrubinger

    Update the relevant .classpath files

    alesj

      From this sticky thread:
      - http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4133184#4133184

      "adrian@jboss.org" wrote:

      2) Update the relevant .classpath files

      ...

      (2) is optional, but it would be friendly, otherwise we end up with different
      subprojects referencing different versions (e.g. because only one uses a new feature)
      and Eclipse gets confused when running tests or showing source.


      Rather than friendly, I see this as unnecessary.
      OK, I guess this was very useful for the projects that didn't have Maven handling the build or any other means of producing the project files.
      I know I would like to have something like that for AS_trunk and IntelliJ. ;-)

      But in our case, it's nothing more than additional work.
      Not to sound rude, but why should we care about .classpath files and not any other IDE project files?

      I bet there is a Maven --> (your) IDE plugin available, so let's all use that and drop those .classpath files.

      Not to mention that if we still decide to support them, we're bypassing what Maven poms actually hold as dependencies, possibly resulting in inconsistency between poms and .classpath.

      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? ;-)

        • 1. Re: Update the relevant .classpath files

           

          "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

            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

               

              "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

                 

                "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

                   

                  "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

                     

                    "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

                       

                      "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

                         

                        "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

                           

                          "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

                             

                            "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

                              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