From mobile apps to microservices, from small startups to big enterprises, Gradle helps teams build, automate and deliver better software, faster.

Gradle Community

Why would you prefer to apply pugins the legacy way?

When I configure modules with `subprojects` or `allprojects`, I need reference to particular extension or task in root `build.gradle`. For example:

```subprojects {
    afterEvaluate {
        extensions.getByType&lt;KotlinProjectExtension&gt;().jvmToolchain {
            (this as JavaToolchainSpec).languageVersion.set(JavaLanguageVersion.of(sdk.versions.jdk.get()))
        }
    }
}```

Well, any usage of `subprojects` or `allprojects` block is bad too. It immediately introduces project coupling and works against more sophisticated features like parallel execution or configuration cache. So using them is highly discouraged anyway. The proper way to share configuration code is to use convention plugins.

And `afterEvaluate` is also bad in almost all cases where it is used, it is usually only symptom treatment and just delays problem to a later and harder debug point in time and always introduces race conditions as the thing meant to wait for could also happen in an `afterEvaluate` block happening after your `afterEvaluate` block.

Instead you should either apply the plugin in question that you want to configure, or react to it being applied using `pluginManager.withPlugin...`

And btw. the version for a plugin in version catalog is not mandatory, it works fine without, as the docs you linked to also describe

I concede using `afterEvaluate` is a bad and will move on from this practice.

Another reason to use legacy plugin application is if a plugin has <https://blog.gradle.org/optional-dependencies|optional dependency>, I still need to configure the capabilities in root `build.gradle` :

```buildscript {
    dependencies {
        classpath("my.plugin") {
            capabilities { ... }
        }
    }
}```

I would have to disagree with your last statement, declaring a plugin without a version throws an `org.gradle.api.InvalidUserDataException` . As of version 7.4.2, `withoutVersion` is only limited to `LibraryAliasBuilder`.

Why do you disagree?
Even your screenshot confirms what I say.

`PluginAliasBuilder` does not have a function `withoutVersion`, only `LibraryAliasBuilder` does.

Hm, that's probably an omission in the API then.
Using the TOML it works fine to have a plugin without version

And regarding the capabilities for plugins.
I didn't try, but if this really prevents using the `plugins { ... }` DSL it imho is a bug in that plugin that should be fixed.
It should maybe instead have different sub-plugins for the use-cases that you apply additionally.

As a work-around you could probably declare this dependency in `buildSrc` build script in `runtimeOnly` scope.

And regarding without version, you could set some fake version and then use it like `libs.plugins.myPlugin.get().pluginId` to only get the id without version

Is the legacy plugin application in any risk of being removed in the future?

Alright it has been a revelation. Thanks for your time and insights. Have a great rest of the day!