From MNG-2031:

Transitive dependencies are cool, however, the limitations are very difficult to work around.

• specification dependencies
• jarjar dependencies (spring.jar includes all spring-xxx.jar, so no need to include them)
• remove warning on relocations for transitive dependencies (it's always difficult to tell users: that's not an error, and we can not do anything)
• poms on ibiblio are all in m2 and never change
• exclusions for transitive deps can be overriden if manually included

One cool feature would be to allow disabling transitive dependencies in the following ways:

• disable all transitive deps
• enable transitive dependencies only for modules of the same project
• enable transitive deps for specific groupIds
• disable transitive deps for specific groupIds
• have a tag/attribute to exclude all transitive deps for one dependency (instead of having list all exclusions)

Adding another possibly featured way to configure:

• disable all transitive deps for certain scopes

(e.g.: I'ld like transitive deps marked for 'runtime' and 'compile', but not for 'test')

The squeakiest tire get the oil first : That would be indeed a much wanted feature.

Gilles

Gilles Tabary

Hi,

I'm wondering why this, in my eyes, important feature won't be fixed in 2.0x but in 2.1 (next year)? The initial request is more than one year old!

My project depends on some jars but NOT on their dependencies. Neither at compile nor at test or runtime. Therefore it makes no sense to download these dependecies at all.

With the current mechanism of using the <exclusions/> element within each dependency separately causes a lot of boilerplate configuration steps. In my case for over 30 dependencies!

I like the idea of having a global <exclusion/> element within <dependencyManagement/> or allowing wildcards for artifactId and groupId or intrdoucing an attribute transitive="false" on the <dependency/> element.

Please make this a higher prio, thanks!

The main issue it that it can't be specified in the current pom model (4.0.0) and updates to the pom model require the next version aka 2.1.

There is a way to detect these creeping in, in dependency:analyze-dep-mgt and in the next enforcer release, there will be a rule that can fail the build when any excluded dependencies are found in the build.

I don't know, I will miss all of the late nights and long weekends I spend analyzing the dependency tree trying to get rid of one stupid JAR file that causes the application not to run properly. What will I do with all my extra time? Wow, maybe I can actually DEVELOP something.

I can just agree to others here, this is indeed a VERY important feature. It would ease the development a lot. As if you currently have such a bogus dependency you'll have to copy and paste every possible exclusion to every dependency. This is really ugly and costs a lot of time.

I'm currently also suffering from the lack of this feature and would be extremely grateful to see this one added
Cheers,
C

It seems to me that the original problem would be solved better by artifact substitution or aliasing rather than more exclusions. e.g if you want to use something reasonable such as slf4j to imitate commons logging usage you want to replace any dependency on commons-logging with one on jcl-over-slf4j. Similarly you might want to swap spec implementations, say to use the geronimo ones no matter which copies the original projects were built against, or use geronimo's activation implementation instead of sun's. This isn't quite the same as what osgi gives you but is quite powerful.

You are right David, that would solve the original problem in an elegant way. Is this an existing feature I missed or should we submit a new jira issue for this?

Aliasing would be nice. But I would also like to be able to specify that, for example, junit-3.8.1 should NEVER be downloaded and never be resolved as a dependency for my projects. I don't ever want junit-3.8.1 and junit-4.5 to both be in the same classpath.

This just became a total showstopper with SpringSource effectively cloning the entire maven dependency set in their "enterprise" repo.
I know that's not maven's fault, but both global exclusions (e.g. as protections again known bad poms) and aliasing (to always substitute slf4j for clogging) would really fix a lot of problems that this has caused.

That's a lovely development. If you use Nexus, you can control which artifacts come from a given repo so you can prevent the springsource repo from polluting your team. There's nothing that can be done inside maven for global exclusions until 3.0 since it requires a model change in the pom.

It's a sad thing that this will never be available for backports because the pom model cannot be changed..

This is a very much awaited feature. And though I like a lot tools of the like of Nexus (Artifactory is also very nice BTW), I think Maven should provide these mechanisms and that maybe 2.1 release was a bit rushed in this prospect.

Is there a timeframe for 3.0 already?

Why is this not planned for 2.2 for example?

Oh, and BTW: my simple wishes http://blog.zepag.org/2009/05/my-wishes-for-better-maven-2.html

Pierre,

The pom format can't be changed until Maven 3.x. The alphas of 3.x are close by, but currently it's focused on 2.x compatibility with the new code and a process to handle pom model changes hasn't been built yet.

For those needing aliasing/substitution, there is a proposal at MNG-4391.

I note that David and Kees were suggesting this a year back.