### Author:  [@iseki0](https://discuss.gradle.org/u/iseki0)
#### Post date: [February 25, 2024, 12:48am UTC](https://discuss.gradle.org/t/when-will-gradle-allow-apply-false-the-core-plugin/47778/1 "2024-02-25T00:48:55Z")
There’re many old threads were facing the same problem. Because of the plugin is a core plugin and it’s already on the classpath. So we can’t apply(false) to it. But if we just remove the plugin line, the Kotlin DSL will not work correctly because of the disappered symbols.
> [@Build only subprojects in a dynamic multi-module project](https://discuss.gradle.org/t/build-only-subprojects-in-a-dynamic-multi-module-project/35512):
>
> Hello guys, Sorry for the vague question, but I have a bad feeling that I’m doing something wrong. There is a root project that contains a huge number of subprojects. Each subproject is a trivial Java sample with source code, tests, and documentation. At the same time, the root project doesn’t have any source code by itself only subfolders and build artifacts. Due to the high number of samples and their simplicity was decided not to create build.gradle.kts for each of them, instead include the…
>
>
> \### Expected Behavior
>
>
> Using the Groovy DSL with multiple sub projects, I co…uld apply plugins in the \`subprojects\` block in the root project without having the plugin applied on the root project (to be able to set common stuff in the \`subprojects\` block, like setting the 'java' and 'application' plugins, dependency management stuff, etc).
>
> \### Current Behavior
>
>
> With the Kotlin DSL, I can't apply plugins in the \`subprojects\` block in the root project without them being included in the \`plugins\` block. Unfortunately, this also applies the plugin on the root project and can cause some issues when trying to run tasks that are present in all subprojects (in my case \`distTar\` from the application plugin).
>
> \### Context
>
>
> We should be able to apply built-in plugins on sub-projects only like when using the Groovy DSL.
> External plugins work fine since we can do \`apply false\` in the plugins block to prevent the plugin from being applied there, but built-in plugins won't let us to this (throwing an exception telling us it would be a no-op : \`\> Plugin 'org.gradle.application' is a core Gradle plugin, which is already on the classpath. Requesting it with the 'apply false' option is a no-op.\`).
>
> \### Steps to Reproduce (for bugs)
>
>
> I've made 2 demo projects \[here\](https://github.com/FredDeschenes/gradle-kotlin-dsl-plugin-bug) which I believe are the equivalent Groovy/Kotlin implementations of the same thing.
>
> \- Checkout the \[project\](https://github.com/FredDeschenes/gradle-kotlin-dsl-plugin-bug)
> \- \`cd groovy\`
> \- \`./gradlew\[.bat\] clean distTar\`
> \- \`app1/build/distributions\` and \`app2/build/distribution\` will have the built packages
> \- \`cd ../kotlin\`
> \- \`./gradlew\[.bat\] clean distTar\`
> \- Gradle error output : \`No value has been specified for property 'mainClassName'\` (for \`:startScripts\` task)
>
> \### Your Environment
>
>
> \* Build scan URL:
> I couldn't get the buildscan plugin to work with the Kotlin DSL (it still outputs the Groovy DSL stuff to add to the project).
Workaround is not work always. Some syntax has no way to workaround.
---
### Author:  [@Vampire](https://discuss.gradle.org/u/Vampire)
#### Post date: [February 26, 2024, 4:10pm UTC](https://discuss.gradle.org/t/when-will-gradle-allow-apply-false-the-core-plugin/47778/2 "2024-02-26T16:10:14Z")
Why should you want to `apply(false)` a built-in plugin?
The only sense of `apply(false)` is, to bring some plugin onto the buildscript classpath.
But the built-in plugins are all available on the buildscript classpath.
So even if `apply(false)` would syntactically work for built-in plugins, it would just be a no-op.
What do you actually want to achieve?
---
### Author:  [@iseki0](https://discuss.gradle.org/u/iseki0)
#### Post date: [February 27, 2024, 2:52am UTC](https://discuss.gradle.org/t/when-will-gradle-allow-apply-false-the-core-plugin/47778/3 "2024-02-27T02:52:21Z")
But if I don’t mention the plugin in `plugins{}` block. I can’t use the configure function of the plugin in the file, even `subproject{}`.
> [@Vampire](#):
>
> The only sense of `apply(false)` is, to bring some plugin onto the buildscript classpath.
Just:
```kotlin
plugins {
// signing // if we commentted the line
}
signing {} // Error: Expression 'signing' cannot be invoked as a function. The function 'invoke()' is not found
```
---
### Author:  [@Vampire](https://discuss.gradle.org/u/Vampire)
#### Post date: [February 27, 2024, 8:43am UTC](https://discuss.gradle.org/t/when-will-gradle-allow-apply-false-the-core-plugin/47778/4 "2024-02-27T08:43:05Z")
Again, having a useless possibility to do `apply(false)` would not change anything.
With `apply(false)` a plugin is only added to the classpath, but not applied and the core plugins already are on the classpath.
To get the type-safe accessors for Kotlin DSL you do not only have to “mention” a plugin in the `plugins { ... }` block, you actually have to apply it.
Because Gradle does only generate type-safe accessors for things it knows will be there at runtime and not fail for “extension not found” for example.
That you cannot use such accessors in `subprojects { ... }` without applying the respective project where you want to use `subprojects { ... }` is one of the various reasons why cross-project configuration like `allprojects [... }`, `subprojects { ... }`, `project(...) { ... }` and similar are bad practice and highly discouraged. The also immediately introduce project coupling which works against some more sophisticated Gradle features and optimizations. To centralize and reuse build logic, better use [convention plugins](https://docs.gradle.org/current/userguide/sharing_build_logic_between_subprojects.html#sec:convention_plugins) in `buildSrc` or an [included build](https://docs.gradle.org/current/userguide/composite_builds.html), for example implemented as [precompiled script plugins](https://docs.gradle.org/current/userguide/custom_plugins.html#sec:precompiled_plugins).
---
### Author:  [@iseki0](https://discuss.gradle.org/u/iseki0)
#### Post date: [February 27, 2024, 11:16am UTC](https://discuss.gradle.org/t/when-will-gradle-allow-apply-false-the-core-plugin/47778/5 "2024-02-27T11:16:19Z")
> [@Vampire](#):
>
> To get the type-safe accessors for Kotlin DSL you do not only have to “mention” a plugin
I found something disagree your sentence. I wrote:
```kotlin
kotlin("jvm") apply false
```
Then it works well as I expected, type-safe accessors generated and the task is not created.
So I think there’s something happend but I don’t know.(Not only jvm, shadow plugin also works.)
> [@Vampire](#):
>
> to use `subprojects { ... }` is one of the various reasons why cross-project configuration like `allprojects [ ... }`, `subprojects { ... }`, `project(...) { ... }` and similar are bad practice and highly discouraged.
I agree, but since the project is really small, create convention plugins is harmful for building time and a little heavy.
---
### Author:  [@Vampire](https://discuss.gradle.org/u/Vampire)
#### Post date: [February 27, 2024, 12:22pm UTC](https://discuss.gradle.org/t/when-will-gradle-allow-apply-false-the-core-plugin/47778/6 "2024-02-27T12:22:02Z")
> Then it works well as I expected, type-safe accessors generated and the task is not created.
> So I think there’s something happend but I don’t know.(Not only jvm, shadow plugin also works.)
Can you please share an [MCVE](https://stackoverflow.com/help/mcve) that shows this?
> I agree, but since the project is really small, create convention plugins is harmful for building time and a little heavy.
Convention plugins are never as harmful as using cross-project configuration.
If you are concerned about last bit of performance, you should adopt configuration cache, because then on cache reuse the whole configuration phase, including building the convention plugins, can be skipped completely.
---
### Author:  [@iseki0](https://discuss.gradle.org/u/iseki0)
#### Post date: [February 27, 2024, 1:50pm UTC](https://discuss.gradle.org/t/when-will-gradle-allow-apply-false-the-core-plugin/47778/7 "2024-02-27T13:50:58Z")
> [@Vampire](#):
>
> Can you please share an [MCVE](https://stackoverflow.com/help/mcve) that shows this?
Maybe you’re right, it’s my wrong. I’m confused the _type-safe accessors_ and the _types_.
When I `apply false` a plugin, I can use its _types_ rather than its _type-safe accessors_ (The types still on classpath).
Sorry…
---
### Author:  [@Vampire](https://discuss.gradle.org/u/Vampire)
#### Post date: [February 27, 2024, 1:52pm UTC](https://discuss.gradle.org/t/when-will-gradle-allow-apply-false-the-core-plugin/47778/8 "2024-02-27T13:52:32Z")
Yes, that’s exactly the effect of `apply(false)` as mentioned, that the plugin is put onto the classpath so you can use its types, without applying the plugin and thus without getting type-safe accessors.
And that’s exactly the reason why `apply(false)` for built-in plugins just does not make any sense. 🙂