Raphael
09/21/2023, 3:25 PM/
/gradlePlugins <-- In here plugins are specified
/subProjectA
/subProjectB
/build.gradle.kts <-- should apply the plugin to all subprojects and should apply the default config
/settings.gradle.kts <-- here the plugin is included
/default-config.gradle.kts
The defualt-config.gradle.kts should look something like this:
apply(plugin = "my-plugin")
myPluginConfig {
foo="bar"
}
The build.gradle.kts should include this config something like this:
...
subprojects {
apply(from = "default-config.gradle.kts")
}
Unfortunately this doesn't work.
1. Because i cannot apply the plugin in the subprojects
container due to Cannot run Project.afterEvaluate(Action) when the project is already evaluated.
2. The default-config.gradle.kts
cannot resolve myPluginConfig
as well as any imports of it.
I have tried countless different scenarios without any luck. Does anyone have an idea on how to do that?Justin Tullgren
09/21/2023, 3:59 PM/
/buildLogic
/buildLogic/settings.gradle.kts
/buildLogic/build.gradle.ks
/project
/project/settings.gradle.kts
/project/build.gradle.kts
/project/module
/project/module/build.gradle.kts
/project/settings.gradle.kts
pluginManagement {
includeBuild("buildLogic")
}
/project/build.gradle.kts
plugins {
id("my.custom.plugin") apply false
}
Raphael
09/21/2023, 4:01 PMJustin Tullgren
09/21/2023, 4:03 PMclass MySettings : Plugin<Settings>
gradle.properties
if you wanted toapply(plugin = "my-plugin")
and to instead use the plugins
dslRaphael
09/21/2023, 4:51 PMVampire
09/21/2023, 8:58 PMGiven you mean usingCopy code/build.gradle.kts <-- should apply the plugin to all subprojects and should apply the default config
allprojects { ... }
or subprojects { ... }
, definitely not. Both are highly discouraged and should not be used as they immediately introduce project coupling which disturbs more sophisticated Gradle features, and makes Gradle builds much harder to understand and much harder to maintain. As Justin said, use (or stay with) convention plugins. If you got a request to change from convention plugins to subprojects { ... }
, just answer with "no, not without a time-machine going back to stone age". 🙂
The defualt-config.gradle.kts should look something like thisDefinitely not. Such legacy script plugins (the ones applied with "apply from" are bad practice and have many bad details and class loader traps that you really want to avoid. Besides that you also do not get type-safe accessors like
myPluginConfig { ... }
in them unless you manually provide them.
Overall, you should just not do it.
You should avoidCannot run Project.afterEvaluate
afterEvaluate
as hell anyway. In 98.7 % of the cases it is the wrong thing to do. It is typically just symptom treatment and shifting the problem to a later much harder to reproduce, debug, and fix time. The main thing using afterEvaluate
causes are ordering and timing problems and race conditions.