Skip to content

Why does this project flatten dependencies? #3918

@pativa

Description

@pativa

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.

Metadata

Metadata

Assignees

Labels

api: spannerIssues related to the googleapis/java-spanner API.

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions