Maven 2 & 3

transitive dependency exclusion fails when classifier specified

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Blocker Blocker
  • Resolution: Not A Bug
  • Affects Version/s: 2.0.9
  • Fix Version/s: None
  • Component/s: Dependencies
  • Labels:
    None
  • Environment:
    Gentoo linux
  • Complexity:
    Intermediate
  • Number of attachments :
    1

Description

I have a profile like the one below. When I enable that profile, maven refuses to exclude the dependencies as specified, unless I remove the classifier. This is basically preventing us from using maven. We will have to stick with ant until this is resolved.

A little bit of background. We have an rmi module and a web module. This profile is in the web module pom. The rmi project creates two different types of jars. One is the rmi server jar, the other the rmi client jar. In the case of the rmi server jar, all the dependencies would be required. And, we allow the rmi server to be run in process (under tomcat). In a case like that, we require all the dependencies. But, when running in standard RMI mode, and using the client jar, we do not need all those dependencies, nor do we want them to be there.

<profile>
  <!-- use full rmi when doing development, even if inproc server -->
  <id>client</id>
  <build>
    <resources>
      <!-- Copy configurations over to webapp folder -->
      <resource>
        <filtering>true</filtering>
        <directory>${basedir}/src/main/resources</directory>
        <excludes>  <!-- Don't need these in production -->
          <exclude>server.properties</exclude>
          <exclude>response_codes.properties</exclude>
        </excludes>
      </resource>
    </resources>
  </build>
  <dependencies>
    <dependency>
      <groupId>ca.athabascau.banner.oros</groupId>
      <artifactId>rmi</artifactId>
      <version>1.1.23-SNAPSHOT</version>
      <scope>compile</scope>
      <classifier>client</classifier>
      <exclusions>
        <exclusion>
          <groupId>ca.athabascau</groupId>
          <artifactId>moneris-test</artifactId>
        </exclusion>
        <exclusion>
          <groupId>com.oracle.ojdbc</groupId>
          <artifactId>ojdbc14</artifactId>
        </exclusion>
        <exclusion>
          <groupId>com.novell</groupId>
          <artifactId>java-ldap</artifactId>
        </exclusion>
        <exclusion>
          <groupId>commons-dbcp</groupId>
          <artifactId>commons-dbcp</artifactId>
        </exclusion>
        <exclusion>
          <groupId>commons-collections</groupId>
          <artifactId>commons-collections</artifactId>
        </exclusion>
        <exclusion>
          <groupId>commons-pool</groupId>
          <artifactId>commons-pool</artifactId>
        </exclusion>
        <exclusion>
          <groupId>cas</groupId>
          <artifactId>casclient</artifactId>
        </exclusion>
        <exclusion>
          <groupId>xerces</groupId>
          <artifactId>xercesImpl</artifactId>
        </exclusion>
        <exclusion>
          <groupId>oro</groupId>
          <artifactId>oro</artifactId>
        </exclusion>
        <exclusion>
          <groupId>xml-apis</groupId>
          <artifactId>xml-apis</artifactId>
        </exclusion>
        <exclusion>
          <groupId>javax.activation</groupId>
          <artifactId>activation</artifactId>
        </exclusion>
      </exclusions>
    </dependency>
  </dependencies>
</profile>

Issue Links

relates to

Bug - A problem which impairs or prevents the functions of the product. MNG-1823 dependencies with classifier mask transitive dependencies of same dependency without classifier

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Trenton added a comment -

Oh, one other thing. I think this MAY be related to this other bug, but perhaps not quite the same?
http://jira.codehaus.org/browse/MNG-1823

Show
Trenton added a comment - Oh, one other thing. I think this MAY be related to this other bug, but perhaps not quite the same? http://jira.codehaus.org/browse/MNG-1823
Hide
Permalink
Trenton added a comment -

On second thought, it's not a show stopper. But, sure is annoying.

Show
Trenton added a comment - On second thought, it's not a show stopper. But, sure is annoying.
Hide
Permalink
Trenton added a comment -

Note the "rmi" dependency in the main dependencies section with the "provided" scope. Also note the "client" profile.

Show
Trenton added a comment - Note the "rmi" dependency in the main dependencies section with the "provided" scope. Also note the "client" profile.
Hide
Permalink
Rares Pop added a comment -

I can confirm this bug and suffering from it.

Show
Rares Pop added a comment - I can confirm this bug and suffering from it.
Hide
Permalink
ol added a comment -

I confirm this bug

Show
ol added a comment - I confirm this bug
Hide
Permalink
Benjamin Bentmann added a comment -

Note the "rmi" dependency in the main dependencies section with the "provided" scope. Also note the "client" profile.

This is misconfiguration/misunderstanding. The relevant snippet from the effective POM when the profile "client" is activated:

<dependencies>
  ...
  <dependency>
    <groupId>ca.athabascau.banner.oros</groupId>
    <artifactId>rmi</artifactId>
    <version>1.1.23-SNAPSHOT</version>
    <scope>provided</scope>
  </dependency>
  <dependency>
    <groupId>ca.athabascau.banner.oros</groupId>
    <artifactId>rmi</artifactId>
    <version>1.1.23-SNAPSHOT</version>
    <classifier>client</classifier>
    <scope>compile</scope>
    <exclusions>
      <exclusion>
        <artifactId>moneris-test</artifactId>
        <groupId>ca.athabascau</groupId>
      </exclusion>
      ...
  </dependency>
</dependencies>

i.e. the WAR project has two dependencies, one on ca.athabascau.banner.oros:rmi:1.1.23-SNAPSHOT:client and one on ca.athabascau.banner.oros:rmi:1.1.23-SNAPSHOT which are considered two different/distinct dependencies due to the classifier. And the exclusions defined on one dependency are only applied to this dependency. I.e. while the transitive dependencies of ca.athabascau.banner.oros:rmi:1.1.23-SNAPSHOT:client are excluded, those of ca.athabascau.banner.oros:rmi:1.1.23-SNAPSHOT are not.

So, simply define the exclusions on the main dependency as well.

Show
Benjamin Bentmann added a comment - Note the "rmi" dependency in the main dependencies section with the "provided" scope. Also note the "client" profile. This is misconfiguration/misunderstanding. The relevant snippet from the effective POM when the profile "client" is activated: <dependencies> ... <dependency> <groupId> ca.athabascau.banner.oros </groupId> <artifactId> rmi </artifactId> <version> 1.1.23-SNAPSHOT </version> <scope> provided </scope> </dependency> <dependency> <groupId> ca.athabascau.banner.oros </groupId> <artifactId> rmi </artifactId> <version> 1.1.23-SNAPSHOT </version> <classifier> client </classifier> <scope> compile </scope> <exclusions> <exclusion> <artifactId> moneris-test </artifactId> <groupId> ca.athabascau </groupId> </exclusion> ... </dependency> </dependencies> i.e. the WAR project has two dependencies, one on ca.athabascau.banner.oros:rmi:1.1.23-SNAPSHOT:client and one on ca.athabascau.banner.oros:rmi:1.1.23-SNAPSHOT which are considered two different/distinct dependencies due to the classifier. And the exclusions defined on one dependency are only applied to this dependency. I.e. while the transitive dependencies of ca.athabascau.banner.oros:rmi:1.1.23-SNAPSHOT:client are excluded, those of ca.athabascau.banner.oros:rmi:1.1.23-SNAPSHOT are not. So, simply define the exclusions on the main dependency as well.

People

  • Assignee:
    Benjamin Bentmann
    Reporter:
    Trenton
Vote (4)
Watch (5)

Dates

  • Created:
    Updated:
    Resolved: