5 Replies Latest reply on Nov 26, 2007 3:17 PM by Adrian Brock

    Strange dependency issue

    Adrian Brock Master

      When I resynched with the microcontainer project this morning,
      it was giving me all lots of errors running the aop-mc-int tests.
      (This was on a clean build).

      I figured out it was building against the wrong version jboss-container
      (a snapshot from a couple of days ago).

      I decided to go through and fix the problems reported by
      dependecy:analyze
      but it is giving me a strange message related to jboss-container in aop-mc-int
      which is probably related to what I saw, although I can't reproduce it now.

      [INFO] ----------------------------------------------------------------------------
      [INFO] Building JBoss Microcontainer AOP MC INT
      [INFO] task-segment: [dependency:analyze]
      [INFO] ----------------------------------------------------------------------------
      [INFO] Preparing dependency:analyze
      [INFO] [resources:resources]
      [INFO] Using default encoding to copy filtered resources.
      [INFO] [compiler:compile]
      [INFO] Nothing to compile - all classes are up to date
      [INFO] [resources:testResources]
      [INFO] Using default encoding to copy filtered resources.
      [INFO] [compiler:testCompile]
      [INFO] Nothing to compile - all classes are up to date
      [INFO] [dependency:analyze]
      [INFO] Used declared dependencies:
      [INFO] org.jboss:jbossxb:jar:2.0.0.CR4:compile
      [INFO] junit:junit:jar:3.8.1:compile
      [INFO] org.jboss:jboss-test:jar:1.0.4.GA:compile
      [INFO] org.jboss:javassist:jar:3.6.0.GA:compile
      [INFO] apache-xerces:xml-apis:jar:2.7.1:compile
      [INFO] org.jboss.microcontainer:jboss-dependency:jar:2.0.0-SNAPSHOT:compile
      [INFO] org.jboss.microcontainer:jboss-kernel:jar:2.0.0-SNAPSHOT:compile
      [INFO] jboss:jboss-logging-spi:jar:2.0.3.GA:compile
      [INFO] org.jboss.aop:jboss-aop:jar:2.0.0.beta1:compile
      [INFO] org.jboss.microcontainer:jboss-kernel:test-jar:tests:2.0.0-SNAPSHOT:test
      [INFO] org.jboss:jboss-common-core:jar:2.2.1.GA:compile
      [INFO] Used undeclared dependencies:
      [WARNING] org.jboss.microcontainer:jboss-container:jar:2.0.0-SNAPSHOT:compile
      [INFO] Unused declared dependencies:
      [INFO] None
      [WARNING] Potential problems discovered.
      [INFO] Found Resolved Dependency / DependencyManagement mismatches:
      [INFO] Ignoring Direct Dependencies.
      [INFO] None
      


      jboss-container is explicitly declared.

      I'd guess this has something to do with it being excluded on the aop artifact?
      But jboss-dependency is also excluded there and comes in via the same
      dependency/artifact, jboss-kernel.

      If I exclude it from the jboss-dependency and jboss-kernel artifacts,
      the spurious error goes away. e.g. see the commented out sections in the pom
       <dependency>
       <groupId>org.jboss.microcontainer</groupId>
       <artifactId>jboss-dependency</artifactId>
       <!-- HERE exclusions>
       <exclusion>
       <groupId>org.jboss.microcontainer</groupId>
       <artifactId>jboss-container</artifactId>
       </exclusion>
       </exclusions-->
       </dependency>
       <dependency>
       <groupId>org.jboss.microcontainer</groupId>
       <artifactId>jboss-kernel</artifactId>
       <!-- HERE exclusions>
       <exclusion>
       <groupId>org.jboss.microcontainer</groupId>
       <artifactId>jboss-container</artifactId>
       </exclusion>
       </exclusions-->
       </dependency>
      


      But why don't I also need to exclude jboss-dependency from jboss-kernel
      in the same way?
      Or more accurately, why do I need to exclude anything since these
      are in the build.

      When do we get the ability to
      <exclude-all-transitive/>
      

      so we're forced to specify consistent dependencies in build/pom.xml
      instead of getting "random" dependencies from unknown places.

      It's a real pain going though all the poms changing, e.g.
       <dependency>
       <groupId>org.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>
      
       <dependency>
       <groupId>org.jboss</groupId>
       <artifactId>jboss-common-core</artifactId>
       <exclusions>
       <exclusion>
       <groupId>jboss</groupId>
       <artifactId>jboss-common-logging-spi</artifactId>
       </exclusion>
       </exclusions>
       </dependency>
       <dependency>
       <groupId>org.jboss</groupId>
       <artifactId>jboss-test</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>
      
      


      over and over again.

      The exclusions (to get a consistent set of dependencies across the projects)
      are getting to be most of the poms. :-(

        • 1. Re: Strange dependency issue
          Paul Gier Master

          There has been some discussion about adding new exclusions in maven 2.1 that would allow you to exclude a certain transitive dependency across the whole tree. I have been pushing for this since I thing it would help in a lot of ways.

          I haven't heard anything about an option to exclude all transitive dependencies though. Is this something that you would really want? Then you would always have to update your transitive deps when any of the direct deps changed versions. It seems like this would have similar maintenance issues, just at a different time.

          • 2. Re: Strange dependency issue
            Adrian Brock Master

             

            "pgier" wrote:

            I haven't heard anything about an option to exclude all transitive dependencies though. Is this something that you would really want? Then you would always have to update your transitive deps when any of the direct deps changed versions. It seems like this would have similar maintenance issues, just at a different time.


            It's most important when transitive depenencies disagree with
            what the local project defines.

            But I personally don't like the way we end with unknown dependencies.
            It's not an issue for the current project directly, but more for those
            further down the line who have conflicts.

            I've even seen this in the MC project where the projects share
            a common definition of dependencies and are developed together.
            For one project it looks consistent, in another because of the addition
            of an extra dependency, it is not.

            mvn dependency:analyze doesn't show everything, so you don't know
            whether it is analyzing them correctly, the eclipse plugin gives
            a better indication of what the totality of dependencies are.

            Maybe being able to a dependency:analyze at the assembly level
            (which you can't do now) so you create a consistent view across
            the subproject dependencies in one place would be an alternate solution to the problem?

            Certainly being able to define the excludes once in microcontainer/build/pom.xml
            would be less verbose :-)

            • 3. Re: Strange dependency issue
              Adrian Brock Master

               

              "pgier" wrote:

              I haven't heard anything about an option to exclude all transitive dependencies though. Is this something that you would really want? Then you would always have to update your transitive deps when any of the direct deps changed versions. It seems like this would have similar maintenance issues, just at a different time.


              It certainly allows you to be very explict about what you want and understand
              what your real dependencies are. :-)

              e.g. I don't care that JBossXB defines apache-xxx:1.2.3, I want to use apache-xxx:2.3.4
              Currently I don't even know that it using it at all without some nontrivial investigation. ;-)

              • 4. Re: Strange dependency issue
                Paul Gier Master

                 

                "adrian@jboss.org" wrote:


                It certainly allows you to be very explict about what you want and understand
                what your real dependencies are. :-)

                e.g. I don't care that JBossXB defines apache-xxx:1.2.3, I want to use apache-xxx:2.3.4
                Currently I don't even know that it using it at all without some nontrivial investigation. ;-)


                If you define apache-xxx:2.3.4 as a direct dependency, it should be using that one. We had some problems with microcontainer in the past because the dependency's groupId changed, so maven didn't know they were the same dep, and that caused the older one to be used.

                You can also use the project info report
                mvn project-info-reports:dependencies


                And that should show what your project is actually using.


                • 5. Re: Strange dependency issue
                  Adrian Brock Master

                   

                  "pgier" wrote:
                  "adrian@jboss.org" wrote:


                  It certainly allows you to be very explict about what you want and understand
                  what your real dependencies are. :-)

                  e.g. I don't care that JBossXB defines apache-xxx:1.2.3, I want to use apache-xxx:2.3.4
                  Currently I don't even know that it using it at all without some nontrivial investigation. ;-)


                  If you define apache-xxx:2.3.4 as a direct dependency,it should be using that one.

                  We had some problems with microcontainer in the past because the dependency's groupId changed, so maven didn't know they were the same dep, and that caused the older one to be used.


                  It still doesn't unless you exclude versions from transitives
                  which takes some effort (e.g. the -X flag to figure out where versions
                  are really coming from).


                  You can also use the project info report
                  mvn project-info-reports:dependencies


                  And that should show what your project is actually using.


                  Yes, that looks more complete. This also shows the container
                  project as undeclared in aop-mc-int which is not true.

                  It still doesn't give a way to verify or resolve dependencies consistently
                  in one place across an assembly. Running the same thing in the
                  microcontainer/build project showed no dependencies at all.