Conditionally applying plugin via plugin-dep-spec

Help/Discuss
1

hi -

q: is there a means to conditionally apply a plugin via the PluginDependencySpec?

eg:

from: PluginDependenciesSpec - Gradle DSL Version 8.10.2

plugins {
  id 'foo.bar' version '1.2' apply pipeline.toString().equals('build')
}

i seem to only be able to get this to work by specifying literal apply values, eg: ‘… apply false’

the need here is to conditionally load a plugin as in some environments the plugin won’t be available, hoping applying false will prevent a plugin download, but i could be wrong on that point.

i am able to get the desired results by adding conditionals in an equivalent ‘legacy’ buildscript/dependencies.

very much appreciate any/all pointers in this regard.

best,

  • james
2

No, this is not possible.

The plugins { ... } block is very restricted in what you can do.
It is extracted and evaluated separately for example to determine which plugins to add to the buildscript classpath.

And even if you could do it like that it would not help.
apply false means “add the plugin to the buildscript classpath so that I can use its classes, but do not apply it”.

This might be an XY problem though.
What’s the actual use-case?
Why would wou want to do that?

3

very much appreciate the verification bjorn

tad worried for if/when the buildscript/dependencies ‘legacy’, as indicated on the gradle-plugins page, is removed.

the use case is a project will have 2 distinct pipelines, one of which is very constrained and does not have the sonarqube-plugin within it’s repository, and adding it is suboptimal. we’ll have another pipeline that basically extends the project’s gradle but adds sq plugin, execs and publishes the report.

i did see something that i can’t seem to find atm that suggested having a non-default foo-build.gradle to which i can (going from memory) ‘apply from ./build.gradle’ that would be really nice in that our needed extensions would literally be in a distinct non-default build.gradle that inherits all the default configurations.

thoughts on this route? also, what is an XY problem?

thx again,

  • james
4

bjorn

First things first, it is Björn or Bjoern, not Bjorn. :wink:

tad worried for if/when the buildscript/dependencies ‘legacy’, as indicated on the gradle-plugins page, is removed

No idea what the Gradle folks have in mind, but I wouldn’t expect it to go anywhere soon, even with the plugins { ... } block being the recommended method, especially as you can use the “legacy” way also to get other libraries into the buildscript classpath.

The plugins { ... } block is especially important when using the Kotlin DSL, which I strongly recommend anyway. By now it is the default DSL, you immediately get typesafe build scripts, acutally useful error messages if you mess up the syntax, and amazingly better IDE support if you use a good IDE like IntelliJ IDEA or Android Studio. And for that using the plugins { ... } block also is essential as you only get types-safe accessors for convenient configuration and IDE assistance for plugins you apply in that block.

But besides that, you could also for example have a convention plugin that you always apply there instead and within the convention plugin then encapsulate the conditional logic.

we’ll have another pipeline that basically extends the project’s gradle but adds sq plugin, execs and publishes the report.

Maybe you should not apply the plugin in the build script then, but inject it in that pipeline using an init script or something like that?

apply from ./build.gradle’ that would be really nice

You should never even consider doing that.
What you talk about are legacy script plugins (the things you use with “apply from”).
They have many quirks and are discouraged.
Besides that it would in no way change your problem in any way, but would just add bad-practice to your setup.

also, what is an XY problem?

XY problem - Wikipedia :slight_smile: