When will gradle allow apply false the core plugin?

Help/Discuss
1

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.

Workaround is not work always. Some syntax has no way to workaround.

2

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?

3

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{}.

Just:

plugins {
 //    signing // if we commentted the line
}
signing {} // Error: Expression 'signing' cannot be invoked as a function. The function 'invoke()' is not found
4

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 in buildSrc or an included build, for example implemented as precompiled script plugins.

5

I found something disagree your sentence. I wrote:

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.)

I agree, but since the project is really small, create convention plugins is harmful for building time and a little heavy.

6

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 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.

7

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…

1 Like
8

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. :slight_smile:

1 Like