Kotlin-dsl-samples: Cannot apply JacocoPlugin by type

Created on 13 Jul 2018  Â·  6Comments  Â·  Source: gradle/kotlin-dsl-samples

Expected Behavior

project.apply<JacocoPlugin>()

Should work.

Current Behavior

Compiler complains with…
image

Caused by:

public class JacocoPlugin implements Plugin<ProjectInternal>

I am rather uneducated on Kotlin's type system capabilities, but I can't see a way to make this work. Seems like Jacoco plugin should be changed to implements Plugin<Project> and do a cast in its implementation.

Most helpful comment

@big-guy The downside would be the types promising more than they should causing code like project.apply<SomeProjectSubtypePlugin>() to succeed no matter what the subtype of Project the plugin expects, i.e., the code below would compile successfully but fail at runtime since Gradle's Project implementation doesn't implement RandomProjectSubtype:

class RandomProjectSubtypePlugin : org.gradle.api.Plugin<RandomProjectSubtype> {
  fun apply(target: RandomProjectSubtype) = Unit
}

interface RandomProjectSubtype : org.gradle.api.Project

project.apply<RandomProjectSubtypePlugin>()

All 6 comments

Workaround:

project.pluginManager.apply(JacocoPlugin::class.java)

This is one incarnation of the Gradle API leaking internal types.
I just checked and looots of core plugins do that.

I opened https://github.com/gradle/gradle/issues/5964 for fixing the plugins api.

If fixing the Gradle public API turns out to be difficult, we could consider changing the apply<T>() function signature on the kotlin-dsl side of things to:

inline fun <reified T : Plugin<out Project>> Project.apply()

What's the downside of inline fun <reified T : Plugin<out Project>> Project.apply()?

Regardless of the downside. I think you - as Gradle - should provide "best
practices" plugins. And providing a plugin with internal apis is by far not
a best practice... No? 🤔

On Fri, Jul 13, 2018, 6:45 PM Sterling Greene notifications@github.com
wrote:

What's the downside of inline fun >
Project.apply()?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/gradle/kotlin-dsl/issues/964#issuecomment-404888774,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AJwYez1ayPQSMNUrJ9lLmYThspFn6AfSks5uGM64gaJpZM4VOF6l
.

@big-guy The downside would be the types promising more than they should causing code like project.apply<SomeProjectSubtypePlugin>() to succeed no matter what the subtype of Project the plugin expects, i.e., the code below would compile successfully but fail at runtime since Gradle's Project implementation doesn't implement RandomProjectSubtype:

class RandomProjectSubtypePlugin : org.gradle.api.Plugin<RandomProjectSubtype> {
  fun apply(target: RandomProjectSubtype) = Unit
}

interface RandomProjectSubtype : org.gradle.api.Project

project.apply<RandomProjectSubtypePlugin>()

Another way is to apply plugins by id:
apply(plugin = "jacoco")
This is the preferred way for core plugins.

Closing as superseded by gradle/gradle#5964

Was this page helpful?
0 / 5 - 0 ratings