I saw an (old) post on the Gradle community that stated plugin version resolution functioned with 'latest.release' or the other notations to always provide latest like '1.+', etc. since Gradle 7.x I am seeing this is not working properly in my build environment with Gradle v9.1.0, but I am unable to see what version of a plugin is actually resolved, with gradlew --info, I only see '1.+' was resolved, but not the specific version that was selected. gradlew dependencies doesn't show the plugins dependency tree -- is there a command that will show the specific plugin versions selected for a build?

I think you’re looking for

./gradlew buildEnvironment

yes I am -- thank you much!

is it the same latest version in Plugin Portal, and Maven ? Maybe when you're using latest it bases itself on Plugin Portal, and when using 1.2.0 it may not find it in Plugin Portal and searchs for it in Central ?

these are in my company's maven repository, not in an external portal.. though it should still resolve?

the debug seems to say that

using repositories [gradleplugins, maven]

so my supposition was that the status may not be the same in these repositories

sometimes maven-metadata.xml doesn’t get properly updated in these company repository mirrors

also says its finding it in the maven repo, which is where we currently publish plugins (odd, but true), and the maven metadata says 1.2.0 is latest

try running Gradle with --refresh-dependencies

oh, could it be something local caching the previous version? i'll check that out

yeah version caching can be a fickle beast

so.... how do i prevent that from happening on other dev's machines? is there a simple solution?

depend on the exact version

we're shortly moving to a version catalog, haven't done the work yet, but will that allow specifying plugin versions as well?

usually depending on a non-exact version is a bad idea

of course but that’s unrelated, you can just use ‘1.2.0’ instead of ‘latest.release’

(using non-exact versions can lead in the best case to non-reproducible builds and in the worst to supply-chain attacks)

super. i totally get not depending on non-exact versions for production dependencies, but this plugin is only quality tools not anything included in a deployable release

that’s until an attacker hijacks it and puts some extra code in there…

trying to minimize the amount of time devs are bumping versions for non-included objects that are common across all of our builds