It might log an annoying warming. As long as they'...

# gradle

[Jared Schlicht]

It might log an annoying warming. As long as they're the same version, it should still be ok.

[Bekzod]

I see, thanks

[mbonnin]

It's not really recommended though. Typically, you should have either:
• your convention plugin react to the presence of the Kotlin plugin (pluginManager.withPlugin("org.jetbrains.kotlin.multiplatform") { } )
or
• your convention plugin apply it
Might be that Gradle debounces plugin applications but it makes the contract of your convention plugin unclear

[Vampire]

I don't agree. As I wrote in the original thread, that's perfectly fine and normal, not only with convention plugins. Applying a plugin a second time is simply a no-op.

If the plugin should do some work in case a specific other plugin is applied, but not if it is not present, reacting is the right way. If applying the plugin does not make sense without the other plugin, it should be applied.

And having and applying a plugin multiple times that way is just fine.

Think for example about two custom plugins that add an extension to the JavaExtension. They would both apply the JavaBasePlugin for example.

[mbonnin]

Same as closing an inputstream. Can you do it twice? Sure it's idempotent.
Should you? I personally prefer that there is only one. It makes it clear who owns the inputstream.

[mbonnin]

I find it an issue in Gradle that plugins dependencies are somewhat implicit.

[Vampire]

I think it is different with streams. In most cases someone owns the stream. He opens it, and he should close it again. With Gradle plugins it is different and also how Gradle itself does it.

But I guess we need to agree we disagree on this one.

[mbonnin]

With Gradle plugins it is different and also how Gradle itself does it.

I wish Gradle did things differently. In the current state, there's a huge global state of mutable plugin extensions.
Who changed java.targetCompatibility ? Good luck finding out when every plugin has access to this at any point of the lifecycle. With proper APIs, these kind of things could be modeled better but agree we're far from it. And maybe never will if this is designed to work like this.