This is a feature that groovy currently lacks and the reasoning/discussion arround this may have been captured in some long issue somewhere so I'm sorry if this ends up being a duplicate.
It would be really nice to be able to read values out of the gradle.properties file inside the plugins code block.
To be able to do something like this:
Have a gradle.properties file with contents like this:
spotlessPlugin.version=3.5.1
And have this in your build file:
plugins {
id("com.diffplug.gradle.spotless") version properties["spotlessPlugin.version"]
}
Compiler complains about not being able to resolve properties within the scope of plugins.
I totally understand why this behaviour makes sense given the nature of plugins block for most code (you don't want if statements in the plugins block).
Doing this would allow you to properties variables between your build.gradle.kts file and your buidSrc/build.gradle.kts. For example, if I want to ensure that my buildSrc and normal build file are both using the same version of the spotless plugin for linting.
Gradle 4.1
------------------------------------------------------------
Build time: 2017-08-07 14:38:48 UTC
Revision: 941559e020f6c357ebb08d5c67acdb858a3defc2
Groovy: 2.4.11
Ant: Apache Ant(TM) version 1.9.6 compiled on June 29 2015
JVM: 1.8.0_92 (Oracle Corporation 25.92-b14)
OS: Mac OS X 10.12.6 x86_64
There is a similar issue at https://github.com/gradle/gradle/issues/1697 which I followed up with a workaround at https://discuss.gradle.org/t/settings-gradle-not-finding-properties-from-gradle-properties/18175/14?u=mkobit that sort of works but seems totally undocumented and may not be interested behavior.
@JLLeitschuh Does this currently work in the buildscript block?
Yes! It does work there.
The issue can be worked around by writing something like this in settings.gradle.kts:
pluginManagement {
repositories {
gradlePluginPortal()
}
resolutionStrategy {
eachPlugin {
if (requested.id.id.startsWith("org.jetbrains.kotlin")) {
gradle.rootProject.extra["kotlinVersion"]?.let { useVersion(it as String) }
}
}
}
}
while having kotlinVersion=1.2.30 in gradle.properties and omitting the version in plugins {} block itself.
That's pretty slick. I like it.
Now, with properties support available in settings.gradle.kts (from https://github.com/gradle/kotlin-dsl/pull/653) you could adapt the comment at https://github.com/gradle/kotlin-dsl/issues/480#issuecomment-374744499
gradle.rootProject.extra["kotlinVersion"]?.let { useVersion(it as String) }
to something like
val kotlinVersion by settings
useVersion(kotlinVersion)
Someone explain to me why we can't do either
1) The plugins block have access to the project scope, so that you can do
plugins {
val myVersion: String by project
id("myPlug") version myVersion
}
or
2) using pluginManagement
// settings.gradle.kts
pluginManagement {
val myVersion: String by project
}
// build.gradle.kts
plugins {
id("myPlug") version myVersion
}
and then have the plugin management scope be available in all plugins blocks?
Thus not falling back to resolutionStrategies for plugins that are already on the gradle plugin portal.
Closing as duplicate of https://github.com/gradle/gradle/issues/1697
Most helpful comment
The issue can be worked around by writing something like this in
settings.gradle.kts:while having
kotlinVersion=1.2.30ingradle.propertiesand omitting the version inplugins {}block itself.