1

There is a dep library one of the modules (module1) of my project depends on. The dependency is declared in a parent's dependencyManagement section.

...
<groupId>group1</groupId>
<artifactId>parent-proj</artifactId>
...
<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>group2</groupId>
            <artifactId>dep</artifactId>
            <version>1</version>
        </dependency>
    </dependencies>
</dependencyManagement>
...



...
<parent>
    <groupId>group1</groupId>
    <artifactId>parent-proj</artifactId>
    ...
</parent>
<artifactId>module1</artifactId>
...
<dependencies>
        <dependency>
            <groupId>group2</groupId>
            <artifactId>dep</artifactId>
        </dependency>
</dependencies>
...

dep in turn depends on subdep which I want to use as a dependency in another module (module2) inheriting from the same parent-proj. The point is to make module2 use the same version of subdep dep depends on without explicit declaration of the version in my project. However, when I try to add a dependency on subdep into module2 Maven doesn't realize what version of subdep has to be used:

...
<parent>
    <groupId>group1</groupId>
    <artifactId>parent-proj</artifactId>
    ...
</parent>
<artifactId>module2</artifactId>
...
<dependencies>
        <dependency>
            <groupId>group2</groupId>
            <artifactId>subdep</artifactId>
        </dependency>
</dependencies>
...

module2$ mvn dependency:tree
...
[ERROR]     'dependencies.dependency.version' for group2:subdep:jar is missing
...

Is there a way to use in a child project a transitive dependency implicitly managed in a parent project?

vect
  • 645
  • 8
  • 16

1 Answers1

1

As dependencyManagement only defines the constraints (like versions), not the real dependencies, why not putting the version alignment in the shared parent pom?

Updating dependency versions may feel odd, but how about a failed build out of the blue, when you neither have the time to find the cause nor to actually fix it.

The owner of dep may upgrade its version dependency regarding subdep even without letting you know through a version increment of dep. You build gets irreproducible.

If your module depends on the API of version 1 of subdep then you most oftenly want to do a 'controlled migration' to version 2. If nothing has changed maybe there is also no reason to increment the version number in the first place.

To reduce the pain, I recommend a look into the Maven version plugin:

For the discussion about how to tell Maven to "just use latest" see:

Community
  • 1
  • 1
Jens Piegsa
  • 7,399
  • 5
  • 58
  • 106
  • Because if I decide to switch to version 2 of `dep` which depends on a newer version of `subdep` such explicitly defined version of `subdep` will override the version of `subdep` from dependency tree of `dep` v.2. So I'll have to realign that explicit definition manually every time I change a version of `dep`. – vect Apr 12 '17 at 17:29
  • "The owner of dep may upgrade its version dependency regarding subdep even without letting you know through a version increment of dep. You build gets irreproducible." - on the other hand overriding a version of `subdep` in `dependencyManagement` I risk having a faulty build because it wouldn't include the version of `subdep` required by `dep`. And because there weren't errors in build time inconsistency of the build would be discovered only during integration tests or even in runtime. – vect Apr 13 '17 at 08:17
  • Yes, when two artifacts (your artifact and `dep`) of one build directly depend on a third (`subdep`) but with two different versions, one will potentially always loose until we have real modules, where these versions can coexist in runtime. – Jens Piegsa Apr 13 '17 at 08:52
  • 1
    If you have lots of artifacts where your want to declare a set of versions to be 'compatible', you can do so by introducing a [`BOM` file](https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html). – Jens Piegsa Apr 13 '17 at 08:56