4
votes

Why doesn't Maven inherit provided dependencies?

My situation:
I have 2 independent projects A and B.
I don't own project A.
A and B use a some of the same libraries:

  • reflections-0.9.9-RC1.jar
  • guava-11.0.2.jar
  • xml-apis-1.0.b2.jar
  • javassist-3.16.1-GA.jar
  • dom4j-1.6.1.jar
  • jsr305-1.3.9.jar

I made project C, which is a plugin for project A, but also uses project B.

Project C pom.xml:

<dependencies>
    <dependency>
        <groupId>com.a</groupId>
        <artifactId>a</artifactId>
        <version>1.0</version>
        <scope>provided</scope>
    </dependency>
    <dependency>
        <groupId>com.b</groupId>
        <artifactId>b</artifactId>
        <version>1.0</version>
        <scope>compile</scope>
    </dependency>
</dependencies>
<build>
    <plugins>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-shade-plugin</artifactId>
            <version>2.4.2</version>
            <executions>
                <execution>
                    <phase>package</phase>
                    <goals>
                        <goal>shade</goal>
                    </goals>
                </execution>
            </executions>
        </plugin>
    </plugins>
</build>

Now I want to make plugins for project C but I can't.
If I create project D with a dependency to project C,
it won't inherit the dependency to project A.
It will if I set the scope to compile but that would shade it into project C which is not useful and would cause duplicates.

So now I have to add dependency to both A and B with every plugin I make.

Compile -This is the default scope, used if none is specified. Compile dependencies are available in all classpaths of a project. Furthermore, those dependencies are propagated to dependent projects.

Provided - This is much like compile, but indicates you expect the JDK or a container to provide the dependency at runtime. For example, when building a web application for the Java Enterprise Edition, you would set the dependency on the Servlet API and related Java EE APIs to scope provided because the web container provides those classes. This scope is only available on the compilation and test classpath, and is not transitive.

Why not?

1
Hm...sorry to say thats because it is defined as it is...What did you expect as an answer? A provided dependency is not transitive, cause that would break the idea of an provided dependency...as you already quoted the documentation....May be i misunderstand your questions here...? - khmarbaise
If so, does that mean there is no way to add a transitive dependency but not shade it in the jar? - Myst
That is a completely different question. - Tunaki
That's true, but it's the next in my situation. I'll try and figure something out. - Myst

1 Answers

5
votes

There is an open bug for that exact requirement: MNG-2205. It is currently in the backlog for version 3 of Maven but I wouldn't get your hopes up: it was created in April 2006 (!).

Quoting Jason van Zyl from that bug report:

It is unlikely we will change the behavior of the provided scope, but it would be possible to create a new 'provided-transitive' if we really wanted this. Changing the definition of existing scopes would be problematic.

Also, quoting Andrew Williams, still from that bug report:

if C wants to use Sybase JConnect then it must declare this as a dependency. A could at any time change it's dependencies and "break" this assumption of C's.

It is wrong to use a dependency that you do not declare.

There is no better answer to this question: the documentation is quite clear on the subject: provided dependencies are not currently transitive. The reason it was initially done this probably revolves around the fact that you should explicitely declare a dependency if you intend to use it.