-
Notifications
You must be signed in to change notification settings - Fork 135
Description
I have a question: Why does this project flatten its dependencies using maven-flatten-plugin
?
I have read #172, but I don't believe any reason was stated there.
I'll try to explain a case where this matters to us:
For example, we manage the version of com.google.guava
to a specific version in a BOM. This guava version uses com.google.guava:failureaccess:1.0.3
.
Due to the flattening, java-spanner
has a direct dependency to com.google.guava:failureaccess:1.0.2
. This means that maven will resolve this artifact to whichever is "closer".
I'll provide an example of when I think this setup causes issues:
<?xml version="1.0" encoding="UTF-8"?>
<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/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>example</groupId>
<artifactId>spanner-dep-example</artifactId>
<version>0-SNAPSHOT</version>
<dependencyManagement>
<dependencies>
<dependency>
<groupId>com.google.cloud</groupId>
<artifactId>google-cloud-spanner</artifactId>
<version>6.94.0</version>
</dependency>
<dependency>
<groupId>com.google.guava</groupId>
<artifactId>guava-bom</artifactId>
<version>33.4.8-jre</version>
<scope>import</scope>
<type>pom</type>
</dependency>
</dependencies>
</dependencyManagement>
<dependencies>
<dependency>
<groupId>com.google.cloud</groupId>
<artifactId>google-cloud-spanner</artifactId>
</dependency>
<dependency>
<groupId>com.google.guava</groupId>
<artifactId>guava</artifactId>
</dependency>
</dependencies>
</project>
With this setup, com.google.guava:failureaccess
will resolve to 1.0.2
:
❯ mvn dependency:tree | grep failureaccess
[INFO] | +- com.google.guava:failureaccess:jar:1.0.2:compile
If guava is moved up before google-cloud-spanner, it will resolve to 1.0.3
.
What I'm trying to say is that this flattening of the bom can cause dependencies to resolve to other versions than what they otherwise would have resolved to. Without flattening, the above example pom would resolve to 1.0.3
regardless of declaration order (as the dependency to failureaccess
is not a direct dependency from this project, but rather a transitive dependency through guava).
Why this matters
While we haven't seen any issues from this yet, we have validations in our build that dependencies resolve to a single version.
I believe other major projects typically do not do this flattening, so I wonder why this project does?
Proposal:
I would propose to stop flattening the pom and let maven resolve its dependencies normally.