developmentOnly and testAndDevelopmentOnly dependencies may prevent implementation dependencies from being included in the uber-jar

[luchob]

Problem:

In my boot project I have both testAndDevelopmentOnly and implementation dependencies. Here is an example:

implementation("org.apache.poi:poi:5.4.1")
implementation("org.apache.poi:poi-ooxml:5.4.1")

testAndDevelopmentOnly ("org.liquibase:liquibase-core:4.32.0")

DISCLAIMER: I know that Liquibase is managed by spring, but this is the easiest way for me to reproduce the issue.

liquibase-core depends on commons-io:commons-io:2.19.0
poi depends on commons-io:commons-io:2.18.0

Gradle chooses 2.19.0 by default. But when I build my application the ueber jar contains neither commons-io:2.18.0 nor commons-io:2.19.0. Using poi fails then with class not found exceptions.

How to reproduce

I have created a small project available in github.

1. Clone the project
2. Navigate to the project directory and build it:

./gradlew clean build -x test

3. You should have now commonsio-bug.jar in the project's build/libs folder.
4. Extract the ueber jar so that you can check its contents, e.g.:

 java -Djarmode=tools -jar ./build/libs/commonsio-bug.jar extract --layers --destination extracted

5. Navigate to extracted/dependencies/lib

Commons IO is not there and poi will throw class not found exceptions because it depends on it.

Dependencies

Spring boot: 3.5.2
io.spring.dependency-management: 1.1.7

[wilkinsona]

Thanks for the report and sample. This appears to affect developmentOnly as well.

[wilkinsona]

The problem only occurs when there are multiple versions of the same dependency involved. As described above, in the testAndDevelopmentOnly configuration, Commons IO's version is 2.19.0 and in the implementation configuration it's 2.18.0.

You can work around the problem by constraining the version of Commons IO so that the version's consistent:

constraints {
	implementation 'commons-io:commons-io:2.19.0'
}

[luchob]

@wilkinsona Yes, thank you! Definitely this is a workaround, I can confirm it.

But I ran in the similar situation with another lib and these workarounds are a bit unstable :)

[wilkinsona]

Here's a better one that's more general.

configurations {
	productionRuntimeClasspath {
		dependencyConstraints.addAllLater providers.provider {
			DependencyConstraintHandler constraints = project.dependencies.constraints
			configurations.runtimeClasspath.incoming.artifacts.artifacts.stream()
					.map { it.id.componentIdentifier }
					.filter { it instanceof ModuleComponentIdentifier }
					.map { constraints.create("${it.group}:${it.module}:${it.version}") }
					.toList()
		}
	}
}

I think we can apply a similar fix in Boot's plugin.