Maven dependency exclusions in pom.xml are not exc

So I have a project in which I've excluded all of the transitive dependencies from one of my dependencies (oracle jdbc stubbornly pulls in all of the jars someone might need, which causes issues for me by replacing my xml parser).

My project's assembly uses a dependencySet to pull in the jars that I need, but this doesn't respect these exclusions at all: the jars that should be excluded are showing up in the final package.

I know that I can explicitly exclude these dependencies in the assembly descriptor itself but its undesirable to have to maintain exclusions in two places and this grows unwieldy if you have lots of exclusions in the pom.xml

Minimal reproducing example:

all files

$ find
.
./src
./src/assembly
./src/assembly/tar.gz.xml
./pom.xml

pom.xml

<?xml version="1.0"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
  <modelVersion>4.0.0</modelVersion>
  <groupId>bug.maven</groupId>
  <artifactId>maven-bug</artifactId>
  <version>1-SNAPSHOT</version>
  <packaging>jar</packaging>
  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-assembly-plugin</artifactId>
        <version>2.6</version>
        <configuration>
          <descriptors>
            <descriptor>src/assembly/tar.gz.xml</descriptor>
          </descriptors>
          <finalName>maven-bug-${project.version}</finalName>
        </configuration>
        <executions>
          <execution>
            <phase>package</phase>
            <goals>
              <goal>attached</goal>
            </goals>
          </execution>
        </executions>
      </plugin>
    </plugins>
  </build>
  <dependencies>
    <dependency>
      <groupId>commons-validator</groupId>
      <artifactId>commons-validator</artifactId>
      <version>1.4.1</version>
      <exclusions>
        <exclusion>
          <groupId>*</groupId>
          <artifactId>*</artifactId>
        </exclusion>
      </exclusions>
    </dependency>
  </dependencies>
</project>

src/assembly/tar.gz.xml

<?xml version="1.0"?>
<assembly>
  <id>pkg</id>
  <formats>
    <format>tar.gz</format>
  </formats>
  <includeBaseDirectory>false</includeBaseDirectory>
  <dependencySets>
    <dependencySet>
      <outputDirectory>/lib</outputDirectory>
      <useProjectArtifact>false</useProjectArtifact>
    </dependencySet>
  </dependencySets>
</assembly>

To reproduce

$ mvn clean package
$ tar tzf target/maven-bug-1-SNAPSHOT-pkg.tar.gz
lib/commons-validator-1.4.1.jar
lib/commons-beanutils-1.8.3.jar
lib/commons-logging-1.2.jar
lib/commons-digester-1.8.1.jar
lib/commons-collections-3.2.1.jar

Expected Results

$ mvn clean package
$ tar tzf target/maven-bug-1-SNAPSHOT-pkg.tar.gz
lib/commons-validator-1.4.1.jar

From what I can tell this is just a bug without documentation in maven. Does anyone have an idea that I'm missing or solution?

回答1:

Like I explained in this answer, Maven assembly plugin (version <= 3.1.0) does not honor wildcards in dependencies exclusions.

This commit fixes it, but the release of the plugin (version 3.1.1) has not been made yet at the moment of writing.

As of now (version <= 3.1.0), the cleanest solution is to explicitly declare all excluded dependencies, without wildcards.

回答2:

There is a simple entry in the assembly descriptor: <useTransitiveDependencies>false</useTransitiveDependencies> which should solve your problem. Furthermore if you think there is some documentation missing you should open a Ticket in JIRA. Ah btw. the goal attached is deprecated and shouldn't be used. In the release 3.0.0 (which is the most recent one it has been removed). See the docs page. There is intentional an difference between the dependencies in your pom file and the ones which you can define in the maven assembly descriptor, cause the descriptor describes what you package and not what is on the classpath there can be differences...and they are not always the same.