Strange dependency issue

[adrian.brock]

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. :-(

[pgier]

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.

[adrian.brock]

"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 :-)

[adrian.brock]

"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. ;-)

[pgier]

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.

[adrian.brock]

"pgier" 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.