[jboss-dev-forums] [Design the new POJO MicroContainer] - Maven and Eclipse (Transitive) Dependencies
adrian@jboss.org
do-not-reply at jboss.com
Sat Mar 8 05:33:57 EST 2008
EXPORTED 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
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4135061#4135061
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4135061
More information about the jboss-dev-forums
mailing list