Maven 2 & 3

Dependency excludes apply to every subsequent dependency, not just the one it is declared under.

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 2.0.1
  • Fix Version/s: 2.0.5
  • Component/s: None
  • Labels:
    None
  • Complexity:
    Intermediate
  • Number of attachments :
    4

Description

If you specify ANY dependency excludes, all dependencies after that one in the pom will also exclude what you specified. They appear to be cumulative on every dependency in that they bleed over into sibling dependencies.
It's easy to test if you add an exclusion to a random dependency. This exclusion should exclude a required transitive dependency that is included by a dependency lower in the list. You will find that the dependency lower in the list no longer includes the required dependency because it is using the filter you declared in the other dependency.

  1. it1019.tgz
    04/Feb/06 1:58 AM
    0.8 kB
    Carlos Sanchez
  2. it1020.tgz
    04/Feb/06 1:59 AM
    0.9 kB
    Carlos Sanchez
  3. MNG-1797-maven-project.patch
    09/Dec/05 3:01 PM
    1 kB
    David Hawkins
  4. MNG-1797-unit-test.patch
    21/Feb/06 12:24 AM
    3 kB
    Carlos Sanchez

Issue Links

Activity

Hide
Stephen Duncan Jr added a comment -

An exclusion also seems to prevent a direct dependency from being honored.

Show
Stephen Duncan Jr added a comment - An exclusion also seems to prevent a direct dependency from being honored.
Hide
Stephen Duncan Jr added a comment -

I screwed up that Issue Link. Is should just be "related to" instead of "depends on".

Show
Stephen Duncan Jr added a comment - I screwed up that Issue Link. Is should just be "related to" instead of "depends on".
Hide
Michael Mattox added a comment -

I just found this issue after running into this bug myself. I think it's pretty serious, I'm very surprised that this hasn't been discussed on the mailing list. My solution was to put the excluded dependency (picocontainer) into my internal repository under a different groupId. Ugly but it works.
I hope the patch can be integrated soon.

Show
Michael Mattox added a comment - I just found this issue after running into this bug myself. I think it's pretty serious, I'm very surprised that this hasn't been discussed on the mailing list. My solution was to put the excluded dependency (picocontainer) into my internal repository under a different groupId. Ugly but it works. I hope the patch can be integrated soon.
Hide
Carlos Sanchez added a comment -

This is verifie, but why would you exclude a dependency that you're adding after? the version will be picked from the one in your pom

Show
Carlos Sanchez added a comment - This is verifie, but why would you exclude a dependency that you're adding after? the version will be picked from the one in your pom
Hide
Cameron Braid added a comment -

Say for example you have this :

<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-hibernate3</artifactId>
<version>2.0-m1</version>
<exclusions>
<exclusion>
<groupId>org.hibernate</groupId>
<artifactId>hibernate</artifactId>
</exclusion>
</exclusions>
</dependency>

<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate</artifactId>
<version>3.1</version>
</dependency>

hibernate 3.1 will be excluced.

Of course, you could always explicitly exclude the specific version

Show
Cameron Braid added a comment - Say for example you have this : <dependency> <groupId>org.springframework</groupId> <artifactId>spring-hibernate3</artifactId> <version>2.0-m1</version> <exclusions> <exclusion> <groupId>org.hibernate</groupId> <artifactId>hibernate</artifactId> </exclusion> </exclusions> </dependency> <dependency> <groupId>org.hibernate</groupId> <artifactId>hibernate</artifactId> <version>3.1</version> </dependency> hibernate 3.1 will be excluced. Of course, you could always explicitly exclude the specific version
Hide
Carlos Sanchez added a comment -

You don't need to exclude it if you're adding it again. No matter what version spring depends on, maven will use 3.1, the one from your pom

Show
Carlos Sanchez added a comment - You don't need to exclude it if you're adding it again. No matter what version spring depends on, maven will use 3.1, the one from your pom
Hide
Grzegorz Slowikowski added a comment -

There is a bug.

This issue is duplicated (be me) in MNG-2032:

http://jira.codehaus.org/browse/MNG-2032

Show
Grzegorz Slowikowski added a comment - There is a bug. This issue is duplicated (be me) in MNG-2032: http://jira.codehaus.org/browse/MNG-2032
Hide
Carlos Sanchez added a comment -

Test for excludes in same pom

Show
Carlos Sanchez added a comment - Test for excludes in same pom
Hide
Carlos Sanchez added a comment -

Test for exclusions in dependencyManagement in parent

Show
Carlos Sanchez added a comment - Test for exclusions in dependencyManagement in parent
Hide
Carlos Sanchez added a comment -

Patch fixes both test cases attached

Show
Carlos Sanchez added a comment - Patch fixes both test cases attached
Hide
Grzegorz Slowikowski added a comment -

Carlos, I think you should remove hibernate dependency from poms in both integration tests. That will simplify tests.

Show
Grzegorz Slowikowski added a comment - Carlos, I think you should remove hibernate dependency from poms in both integration tests. That will simplify tests.
Hide
Carlos Sanchez added a comment -

That also tests transitive exclusions

Show
Carlos Sanchez added a comment - That also tests transitive exclusions
Hide
Grzegorz Slowikowski added a comment -

Maybe it would be better to separate these two cases (direct and transitive exclusions). Hibernate-3.0.5 pom is not simple and some other potential error might interfere with this issue unpredictibly changing result. Without hibernate dependency integration tests are very simple. What do you think about splitting these tests into 4?

Show
Grzegorz Slowikowski added a comment - Maybe it would be better to separate these two cases (direct and transitive exclusions). Hibernate-3.0.5 pom is not simple and some other potential error might interfere with this issue unpredictibly changing result. Without hibernate dependency integration tests are very simple. What do you think about splitting these tests into 4?
Hide
Carlos Sanchez added a comment -

I thnik this test sover the issue, not sure though.

Show
Carlos Sanchez added a comment - I thnik this test sover the issue, not sure though.
Hide
John Casey added a comment -

I'm going to try to get this in, since it's so well tested. I've got the patches/tests in place locally, but am out of time for testing right now. I'll resume tomorrow, time permitting.

Show
John Casey added a comment - I'm going to try to get this in, since it's so well tested. I've got the patches/tests in place locally, but am out of time for testing right now. I'll resume tomorrow, time permitting.
Hide
Carlos Sanchez added a comment -

I don't think we should fix this until we have global exclusions MNG-1977, it'll hurt more than help.

Show
Carlos Sanchez added a comment - I don't think we should fix this until we have global exclusions MNG-1977, it'll hurt more than help.
Hide
John Casey added a comment -

bumping this back to 2.0.4, since the general consensus is this isn't ready yet.

Show
John Casey added a comment - bumping this back to 2.0.4, since the general consensus is this isn't ready yet.
Hide
Carlos Sanchez added a comment -

It is a problem when in the dependencyManagement you use a exclusion but in some of the projects you want to include that previously excluded dep.

Show
Carlos Sanchez added a comment - It is a problem when in the dependencyManagement you use a exclusion but in some of the projects you want to include that previously excluded dep.
Hide
Joerg Schaible added a comment -

Such an exclusion is quite normal if you use the concept of a super POM. If 1 of 100 POMs needs the additional dependencies (e.g. because they are required for something completely different), it will have them added manually - and the project simply fails currently.

Show
Joerg Schaible added a comment - Such an exclusion is quite normal if you use the concept of a super POM. If 1 of 100 POMs needs the additional dependencies (e.g. because they are required for something completely different), it will have them added manually - and the project simply fails currently.
Hide
Andreas Schildbach added a comment -

This issue is very annoying.

There are several POMs on ibiblio that are missing <scope>provided</scope> from their javax.servlet, servlet-api dependency. I tried to fix this by excluding the dependency from the affected dependency path, and including the dependency in my POM (using the correct scope) again. Due to the behaviour of the exclude-mechanism, this approach does not work (and there does not seem to be any alternative, does it?)

Show
Andreas Schildbach added a comment - This issue is very annoying. There are several POMs on ibiblio that are missing <scope>provided</scope> from their javax.servlet, servlet-api dependency. I tried to fix this by excluding the dependency from the affected dependency path, and including the dependency in my POM (using the correct scope) again. Due to the behaviour of the exclude-mechanism, this approach does not work (and there does not seem to be any alternative, does it?)
Hide
Carlos Sanchez added a comment -

you don't need to exclude them to chenge the scope, just add it with the right one

Show
Carlos Sanchez added a comment - you don't need to exclude them to chenge the scope, just add it with the right one
Hide
John Casey added a comment -

Applied the code patch, but I added a simpler unit test.

Show
John Casey added a comment - Applied the code patch, but I added a simpler unit test.

People

Vote (11)
Watch (8)

Dates

  • Created:
    Updated:
    Resolved: