1 2 Previous Next 16 Replies Latest reply on Jul 12, 2007 3:21 PM by kconner

    MAVEN: build change

    kconner

      I have been trying to fix up the build so that the last remaining hudson failure is handled. Unfortunately I have been seeing failures which are not evident in hudson.

      It appears that these failures are a consequence of the version of maven I am using, in particular the way in which it handles conflicts during the transitive dependency resolution.

      To fix this I went through the poms and tidied up the dependency management, moving the version information into the parent pom. I now have a clean build on maven 2.0.6 and 2.0.7 on my local machine.

      Does anyone object to having this checked in?

      Does anyone object to enforcing the maven version through the pom prerequisite? If not, which version? 2.0.7?

      Which version does hudson use BTW?

        • 1. Re: MAVEN: build change

          Can you explain what the pros and cons are?

          I asked for all dependencies to be explicitly listed in the super pom in the build project
          and only that version used.

          I don't know whether Maven supports such a configuration.

          i.e.
          1) raise an error if there is a conflict
          2) raise an error for non-explicit transitive dependencies

          I know there are reports that can be run, but as far as I am aware nobody is doing that
          (or a way to enforce it). Checking it just before a release is really too late.
          It would mean redoing all the testing with new dependencies.

          It would have to be done on all dependent projects as well, e.g. the current common
          release is a mess as far as this concerned. Even its own internal project
          references are out-of-step. :-)

          • 2. Re: MAVEN: build change

            And the same is true of the our build:

            e.g.

            [ejort@warjort microcontainer]$ grep -ri jboss-test *
            aop-mc-int/.classpath: <classpathentry kind="var" path="M2_REPO/jboss/jboss-test/1.0.3.GA/jboss-test-1.0.3.GA.jar"/>
            aop-mc-int/pom.xml: <artifactId>jboss-test</artifactId>
            aop-mc-int/.svn/text-base/pom.xml.svn-base: <artifactId>jboss-test</artifactId>
            aop-mc-int/.svn/text-base/.classpath.svn-base: <classpathentry kind="var" path="M2_REPO/jboss/jboss-test/1.0.3.GA/jboss-test-1.0.3.GA.jar" sourcepath="M2_REPO/jboss/jboss-test/1.0.3.GA/jboss-test-1.0.3.GA-sources.jar"/>
            classloader/.classpath: <classpathentry kind="var" path="M2_REPO/jboss/jboss-test/1.0.4-SNAPSHOT/jboss-test-1.0.4-SNAPSHOT.jar"/>
            classloader/pom.xml: <artifactId>jboss-test</artifactId>
            


            This example leads to "IncompatibleClassChangeError" when running tests under eclipse.

            • 3. Re: MAVEN: build change
              kconner

               

              "adrian@jboss.org" wrote:
              Can you explain what the pros and cons are?

              The negative side is that the transitive dependency analysis performed by certain versions of maven appears to be flawed. The specific example I had this morning was caused by the inclusion of two different versions of jboss-test in our poms. The old version was disabled but this also disabled some of the dependencies of the newer version!

              The consequence of this was that a number of tests within deployers-vfs were failing because the oswego library was no longer on the classpath.
              "adrian@jboss.org" wrote:
              I asked for all dependencies to be explicitly listed in the super pom in the build project and only that version used.

              This is what I have done. They are now listed in dependencyManagement sections and these supplement the dependency specifications in the pom. This can still be overridden locally if needed.

              "adrian@jboss.org" wrote:
              I don't know whether Maven supports such a configuration.

              i.e.
              1) raise an error if there is a conflict
              2) raise an error for non-explicit transitive dependencies

              I don't believe there is any way to force the build to terminate if you have a conflict. The resolution mechanism gives precedence to the version which is configured closest to the pom IIRC, unless it is specified in the dependencyManagement section.

              "adrian@jboss.org" wrote:
              It would have to be done on all dependent projects as well, e.g. the current common
              release is a mess as far as this concerned. Even its own internal project
              references are out-of-step. :-)

              Yes, that would also need checking in that case.

              • 4. Re: MAVEN: build change

                 

                "Kevin.Conner@jboss.com" wrote:

                I don't believe there is any way to force the build to terminate if you have a conflict. The
                resolution mechanism gives precedence to the version which is configured closest to the
                pom IIRC, unless it is specified in the dependencyManagement section.


                What I want to be able to say is in "build"
                'the common version for jboss-test is 1.4-SNAPSHOT"
                in one of the projects
                'I use jboss-test"
                so it is a dependency of my project.

                I don't want all the dependencies from "build" being dragged through into my project.

                Is that how it works?

                If so, then we can add a big warning in each pom.
                <!-- SPECIFY THE VERSION YOU WANT TO USE IN ../build/pom.xml NOT HERE -->
                


                • 5. Re: MAVEN: build change
                  kconner

                   

                  "adrian@jboss.org" wrote:
                  And the same is true of the our build:

                  It's our build I am fixing :)

                  • 6. Re: MAVEN: build change
                    kconner

                     

                    "adrian@jboss.org" wrote:
                    What I want to be able to say is in "build"
                    'the common version for jboss-test is 1.4-SNAPSHOT"
                    in one of the projects
                    'I use jboss-test"
                    so it is a dependency of my project.


                    The dependencyManagement section specifies the version and scope of the dependency. You would still specify the dependency in the pom but would not require the version nor the scope.

                    "adrian@jboss.org" wrote:
                    I don't want all the dependencies from "build" being dragged through into my project.

                    They won't be, this is the dependency metadata.

                    "adrian@jboss.org wrote:
                    If so, then we can add a big warning in each pom.
                    <!-- SPECIFY THE VERSION YOU WANT TO USE IN ../build/pom.xml NOT HERE -->
                    

                    Sounds like a good idea to me :)

                    • 7. Re: MAVEN: build change
                      kconner

                      Should I commit the pom changes?

                      With our stuff tidied up there are still a few conflicts

                      * javassist/javassist/3.5-SNAPSHOT/javassist-3.5-SNAPSHOT.jar
                      org/jboss/javassist/3.6-beta/javassist-3.6-beta.jar

                      javax/activation/activation/1.1/activation-1.1.jar
                      sun-jaf/activation/1.0.2/activation-1.0.2.jar

                      ant/ant/1.6.5/ant-1.6.5.jar
                      * org/apache/ant/ant/1.7.0/ant-1.7.0.jar

                      * - we include these explicitly

                      I also noticed that the deployers project is still present, was this not replaced by all the deployer-* projects?

                      • 8. Re: MAVEN: build change

                        Yes, commit them.

                        We should be using the latest of everything I think so we can find the problems earlier.
                        There's a long discussion on sun-jaf, what uses ant?

                        The deployers project just needs archiving somewhere.

                        • 9. Re: MAVEN: build change
                          kconner

                           

                          "adrian@jboss.org" wrote:
                          Yes, commit them.

                          Okay, will do.
                          "adrian@jboss.org" wrote:
                          We should be using the latest of everything I think so we can find the problems earlier

                          I'll update javassist in that case.
                          "adrian@jboss.org" wrote:
                          There's a long discussion on sun-jaf, what uses ant?

                          Sorry, my mistake. The only explicit part where ant is mentioned is within aop-mc-int (ant-junit is part of the build).

                          The dependencies are showing jboss-aop using ant 1.6.5 and jboss-test using 1.7.0.

                          "adrian@jboss.org" wrote:
                          The deployers project just needs archiving somewhere.

                          In subversion not sufficient for this?

                          • 10. Re: MAVEN: build change

                             

                            "Kevin.Conner@jboss.com" wrote:

                            "adrian@jboss.org" wrote:
                            The deployers project just needs archiving somewhere.

                            In subversion not sufficient for this?


                            Yes, but svn is a tool. It can do
                            svn move url-of-deployers somewhere-else
                            but it can't decide what the value of somewhere-else should be. :-)


                            • 11. Re: MAVEN: build change
                              kconner

                               

                              "adrian@jboss.org" wrote:

                              Yes, but svn is a tool. It can do
                              svn move url-of-deployers somewhere-else
                              but it can't decide what the value of somewhere-else should be. :-)

                              I guess I was thinking more along the lines of
                              svn delete deployers
                              svn co -r XXXX

                              :)

                              • 12. Re: MAVEN: build change

                                Ok, if you tag it first, so it is easy to find.

                                • 13. Re: MAVEN: build change
                                  kconner

                                  I have checked in the modified poms and regenerated the eclipse project/classpath files.

                                  Can someone please check and see if anything is amiss?

                                  • 14. Re: MAVEN: build change
                                    kconner

                                     

                                    "adrian@jboss.org" wrote:
                                    Ok, if you tag it first, so it is easy to find.

                                    It looks as if the changes were made in revision 63690, so I'll tag revision 63689. Any preference for a name?

                                    1 2 Previous Next