5 Replies Latest reply on Sep 3, 2007 6:07 AM by adrian.brock

    Maven depency issues

    pgier

      I just wanted to bring up some of the issues with dependencies in maven that came up recently. Here is a summary of the issues and how to deal with them, as far as I see it.

      Classpath ordering in maven
      Currently, maven puts transitive dependencies before direct dependencies in the compile and test classpaths. I believe this is incorrect, and I will be submitting a patch to reverse this, but it won't be available until the next maven version. It normally isn't an issue, unless there are two different versions of the same artifact in the dependency tree. The way to get around this, is to exclude the conflicting versions from the transitive dependencies.

       <dependency>
       <groupId>jboss</groupId>
       <artifactId>jbossxb</artifactId>
       <exclusions>
       <exclusion>
       <groupId>jboss</groupId>
       <artifactId>jboss-common-core</artifactId>
       </exclusion>
       <exclusion>
       <groupId>jboss</groupId>
       <artifactId>jboss-common-logging-spi</artifactId>
       </exclusion>
       </exclusions>
       </dependency>
      


      The easiest way that I know of to find these conflicting dependencies is by using the dependencies project info report

      mvn project-info-reports:dependencies

      It's a pita to go through all the modules and find instances of these conflicts, but someone (maybe me) should go through the mc modules and fix them.

      Another command that can help clean up dependencies is this one:

      mvn dependency:analyze

      The report will tell you if you have unused dependencies listed, or if you are directly dependent on one of your transitive dependencies. When I have time, I plan to add a feature to this plugin that will tell you if you are including two versions of the same artifact.

      Non-deterministic builds?
      As far as I have seen, the classpath ordering seems to be the same every time. I think when Adrian had a different result, it was probably do to an out of date pom, or possibly something different in the local repository. Anyway, I don't think this is an issue because as far as I've seen, the ordering of the dependencies is consistent.

      Releases/assembly
      The assembly plugin can be used to package up dependencies with the project. As long as the conflicting versions are excluded from the transitive dependencies, we should always get the correct version included in the release. The assembly plugin will also have the same behaviour during a normal build as during a release, so there shouldn't be any difference in the generated artifact when doing the release, or when re-creating the release at a later time.

      Hopefully this addresses some of the concerns that people have had about the maven builds. Obviously, all this is open to discussion :)


        • 1. Re: Maven depency issues
          starksm64

          The main question is how the artifacts seem to be getting out of date for the mc projects. For the case I just ran into it could be that javac is not picking up dependencies correctly in terms of rebuilding classes and not a mvn issue.

          • 2. Re: Maven depency issues
            starksm64

            Looking at the jdk5 javac docs, I don't see any dependency related options. I thought there used to be such a thing. I don't know how throughly class to class file dependency checking is done then.

            • 3. Re: Maven depency issues
              pgier

               

              "scott.stark@jboss.org" wrote:
              The main question is how the artifacts seem to be getting out of date for the mc projects. For the case I just ran into it could be that javac is not picking up dependencies correctly in terms of rebuilding classes and not a mvn issue.


              I think the issue that you were seeing was just because you hadn't built those artifacts in a while, and no one updated the snapshots in a while. Running "mvn deploy" from the root dir, should upload the updated snapshots.

              • 4. Re: Maven depency issues

                In the ant/buildmagic build of jbossas we have an extra task before
                every compile to fix the broken dependency checking of javac

                 <!-- Remove classes which depend on changed files, so they will rebuild. -->
                 <depend srcdir="${source.java}:${build.gen-src}"
                 destdir="${build.classes}"
                 dump="${javac.depend.dump}"
                 closure="${javac.depend.closure}">
                 <include name="${javac.includes}"/>
                 <exclude name="${javac.excludes}"/>
                 </depend>
                


                Is there a similar option for maven?

                • 5. Re: Maven depency issues

                   

                  "pgier" wrote:

                  The easiest way that I know of to find these conflicting dependencies is by using the dependencies project info report

                  mvn project-info-reports:dependencies

                  It's a pita to go through all the modules and find instances of these conflicts, but someone (maybe me) should go through the mc modules and fix them.

                  Another command that can help clean up dependencies is this one:

                  mvn dependency:analyze

                  The report will tell you if you have unused dependencies listed, or if you are directly dependent on one of your transitive dependencies. When I have time, I plan to add a feature to this plugin that will tell you if you are including two versions of the same artifact.


                  These tools should be used before any release anyway.

                  We need to make sure we are not transitively depending on snapshots
                  or things we don't want to depend on. e.g. maybe dependning on
                  alpha/beta version of a project when we do a final release.