Gregory BOISSINOT wrote:
Hello,
I use Maven 2 for almost 2 years now.
The Maven distribution version succeeds one another and I don’t understand
why you always cannot choice to exclude transitive dependency for your
dependency framewok.
But you can do that. More on that below...
For example, if you want to package in your web application
“commons-logging” on version “1.1”, and you do not want the “log4j”,
“logkit”, “avalon-framework” and especially “javax.servlet” that it must not
include in your WEB-INF/lib directory for a web application.
So, you must write just for “commons-logging” :
<dependency>
<groupId>commons-logging</groupId>
<artifactId>commons-logging</artifactId>
<version>1.1</version>
<exclusions>
<exclusion>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
</exclusion>
<exclusion>
<groupId>logkit</groupId>
<artifactId>logkit</artifactId>
</exclusion>
<exclusion>
<groupId>avalon-framework</groupId>
<artifactId>avalon-framework</artifactId>
</exclusion>
<exclusion>
<groupId>javax.servletjavax.servlet</groupId>
<artifactId>servlet-api</artifactId>
</exclusion>
</exclusions>
</dependency>
Yes, it's true that commons-logging 1.1 is one of the most criticized
poms in the central repo. There are two reasons for that; it is a very
widely used library and the POM for that version sucked. The reason it
sucked was because it was automatically converted from a Maven 1 POM,
and the conversion wasn't very good.
I therefor consulted the maven users mailing list, when I was preparing
the 1.1.1 release of commons-logging. After the release I haven't heard
a single complaint about the pom, either here or on the commons user
list. So we (collectively) must have done a decent job of fixing it.
My advice to you is to immediately upgrade all your commons-logging
dependencies to version 1.1.1.
In a project, if you depend of many framework, you will obtain a pom.xml
very spacious and not maintainable. Suddenly, they lose the interest of
Maven.
If a project doesn't maintain a pom for their artifacts, you as a user
can supply a pom for it to the central repository. See
http://maven.apache.org/guides/mini/guide-maven-evangelism.html
In this example, you can’t use the “provided” scope that not gets transitive
dependency because I want to inlude it in my package.
And I can’t use the following section because the “runtime” scope gets
transitive dependency (it is normal) :
<dependency>
<groupId>commons-logging</groupId>
<artifactId>commons-logging</artifactId>
<version>1.1</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>commons-logging</groupId>
<artifactId>commons-logging</artifactId>
<version>1.1</version>
<scope>runtime</scope>
</dependency>
The problem is that the common-logging maven descriptor is very poor.
They should use for theirs dependency provided scope for “servlet-jar” that
is not transitive or the <optional> to true for the other dependency.
You can’t control the framework distribution, so it misses the control of
the transitive dependency in the leaf tree.
What you can in cases like this, if there is no new version of the
artifact with a fixed POM available, is to exclude the transitive
dependencies that you don't want. You can read more about this at
http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html
What do you think about?
Thanks
--
Gregory BOISSINOT
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
