You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Gregory BOISSINOT <gr...@gmail.com> on 2008/04/22 19:53:23 UTC
A poor dependency management
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.
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>
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.
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 do you think about?
Thanks
--
Gregory BOISSINOT
--
View this message in context: http://www.nabble.com/A-poor-dependency-management-tp16825387s177p16825387.html
Sent from the Maven - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: A poor dependency management
Posted by Wayne Fay <wa...@gmail.com>.
You should try version 1.1.1 of this artifact instead. The
commons-logging people fixed this by adding optional tags etc.
And in the future, you are welcome (and invited!) to complain (loudly)
to the dev team responsible for a given artifact about their poms when
they are not working as you expect/require. But this isn't really
appropriate to complain about here, IMO.
Wayne
On 4/22/08, Gregory BOISSINOT <gr...@gmail.com> 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.
>
> 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>
>
> 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.
>
> 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 do you think about?
>
>
> Thanks
> --
> Gregory BOISSINOT
> --
> View this message in context: http://www.nabble.com/A-poor-dependency-management-tp16825387s177p16825387.html
> Sent from the Maven - Users mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: A poor dependency management
Posted by Dennis Lundberg <de...@apache.org>.
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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org