BOM tries to use parameterized project.version as its own version

[Thunderforge]

Consider the following build.gradle file:

plugins {
    id 'java'
    id "io.spring.dependency-management" version "1.0.12.RELEASE"
}

repositories {
    mavenCentral()
}

dependencies {
    implementation "mysql:mysql-connector-java:8.0.29"
}

Running gradlew clean build compiles successfully. But running gradlew clean build -Dproject.version=123 results in the following error:

Execution failed for task ':compileJava'.
> Could not resolve all files for configuration ':detachedConfiguration41'.
   > Could not find com.google.protobuf:protobuf-bom:123.
     Searched in the following locations:
       - https://repo.maven.apache.org/maven2/com/google/protobuf/protobuf-bom/123/protobuf-bom-123.pom
     If the artifact you are trying to retrieve can be found in the repository but without metadata in 'Maven POM' format, you need to adjust the 'metadataSources { ... }' of the repository declaration.
     Required by:
         project :

Note that the version of protobuf-bom it is searching for is 123, the same version that we are passing in.

I don't know what is special about mysql-connector-java that is producing this behavior, but it's what we were able to determine as the problem. If you comment out that dependency or switch it with a different dependency (say, commons-lang-3), compilation works again.

This bug is similar to #315, although the fix for that (included in 1.0.12.RELEASE) didn't seem to fix this issue.

[wilkinsona]

mysql:mysql-connector-java:8.0.29 depends on com.google.protobuf:protobuf-java:3.19.4 and the parent of protobuf-java has the following in its pom:

<dependency>
    <groupId>com.google.protobuf</groupId>
    <artifactId>protobuf-bom</artifactId>
    <version>${project.version}</version>
    <type>pom</type>
    <scope>import</scope>
</dependency>

It's the use of ${project.version} that's causing the problem. It's resolved against the JVM's system properties and you have configured the project.version system property to have a value of 123. Unlike #315 which prevented using the Gradle's Project's version, I don't think it's as clear-cut that use of a system property should be prevented.

Why are you setting the project.version system property? If you are trying to configure the Gradle project's version, you can use -Pversion=123 or -Dorg.gradle.project.version=123

[Thunderforge]

I've confirmed that you are correct: setting project.version does not work as we had planned.

As often happens in business, I've inherited a project that someone else set up. It seems that what they were wanting to do was set the Gradle project's version when, as you said, they should instead have done -Dorg.gradle.project.version=123

But we also had a fallback where we queried our CI's environment variables to get the proper version. The parameter passing never worked and the fallback always worked. So I've removed the parameter passing and now the project builds as intended.

It still might be nice if the dependency management plugin guarded against this or logged a warning. But at any rate, we've determined that the error was improper behavior on our end.

[wilkinsona]

Thanks for the update, @Thunderforge. As this was a misconfiguration on your end, I'm reluctant to make a change for fear of it causing a regression. If we see more reports of the same problem we can of course reconsider but I'm going to close this one for now.