Maven and Eclipse (Transitive) Dependencies
adrian.brock Mar 8, 2008 5:33 AMEXPORTED DEPENDENCIES
I've been through all the projects and fixed up all the dependncies
such that we are not exporting stupid things during the compile.
NOTE: Some of these really need fixing in the original project.
i.e. making them optional
Others are because the projects are using older versions
Examples are
common-core
<dependency> <groupId>org.jboss</groupId> <artifactId>jboss-common-core</artifactId> <version>2.2.3.GA</version> <exclusions> <exclusion> <groupId>jboss</groupId> <artifactId>jboss-common-logging-spi</artifactId> </exclusion> <exclusion> <groupId>apache-httpclient</groupId> <artifactId>commons-httpclient</artifactId> </exclusion> <exclusion> <groupId>apache-slide</groupId> <artifactId>webdavlib</artifactId> </exclusion> <exclusion> <groupId>apache-xerces</groupId> <artifactId>xml-apis</artifactId> </exclusion> </exclusions> </dependency>
jboss-test - also made optional:
<dependency> <groupId>org.jboss</groupId> <artifactId>jboss-test</artifactId> <optional>true</optional> <exclusions> <exclusion> <groupId>jboss</groupId> <artifactId>jboss-common-core</artifactId> </exclusion> <exclusion> <groupId>jboss</groupId> <artifactId>jboss-common-logging-spi</artifactId> </exclusion> <exclusion> <groupId>jboss</groupId> <artifactId>jboss-common-logging-log4j</artifactId> </exclusion> <exclusion> <groupId>ant</groupId> <artifactId>ant</artifactId> </exclusion> <exclusion> <groupId>ant</groupId> <artifactId>ant-junit</artifactId> </exclusion> <exclusion> <groupId>log4j</groupId> <artifactId>log4j</artifactId> </exclusion> </exclusions> </dependency>
aop
<dependency> <groupId>org.jboss.aop</groupId> <artifactId>jboss-aop</artifactId> <exclusions> <exclusion> <groupId>ant</groupId> <artifactId>ant</artifactId> </exclusion> <exclusion> <groupId>apache-xerces</groupId> <artifactId>xml-apis</artifactId> </exclusion> <exclusion> <groupId>javassist</groupId> <artifactId>javassist</artifactId> </exclusion> <exclusion> <groupId>org.jboss</groupId> <artifactId>jboss-common-core</artifactId> </exclusion> <exclusion> <groupId>jboss</groupId> <artifactId>jboss-common-logging-spi</artifactId> </exclusion> <exclusion> <groupId>jboss</groupId> <artifactId>jboss-common-logging-log4j</artifactId> </exclusion> <exclusion> <groupId>org.jboss.microcontainer</groupId> <artifactId>jboss-container</artifactId> </exclusion> <exclusion> <groupId>org.jboss.microcontainer</groupId> <artifactId>jboss-dependency</artifactId> </exclusion> </exclusions> </dependency>
TODO: I've done this for the test compilation.
I'm still seeing things like xerces-2.7.1 leeking in via jboss-test?
in some places instead of 2.9.1 defined by JBossXB (see below).
TRANSITIVE DEPENDENCIES
Additionally I've allowed more transitive dependencies.
i.e. I don't put common-core commons-logging in every project,
I just let it transitively depend on an earlier project
I've done the same thing for eclipse's .classpath files
by making earlier projects use export="true" so it reduces
the number of places to make a version change.
EXTERNAL TRANSITIVE DEPDNENCIES
Finally, in some cases I allow external projects to define the version.
This makes sense in limited cases where that project is the core user
of that artificat.
e.g. I just let jbossxb define the xerces-impl, stax, jaxb versions to use
e.g.2. I let aop define trove and qdox (I think qdox should be optional in aop?)
We could also do some others?
e.g. jboss-common-core defines common-jboss-logging-spi?
e.g.2. jboss-test defines junit?
In other cases it is more difficult.
e.g. jboss-common-core and javassist are entering as dependencies
from multiple paths so we have to explicitly define them multiple times
at the entry points to get a consistent version
Taking jboss-common-core as the example, it enters in our depdendency tree
by a number of roots (which get excluded) and in practice we have to
define it mulitple times in dependency, classloader, deployers-core-spi