you need to refer to extension classes/convention ...

# announcements

[araqnid]

you need to refer to extension classes/convention classes more explicitly in Kotlin DSL, they don't magically appear as extension properties on the project

[Florian Wiesner]

do you know any good reference?

[araqnid]

e.g. the<JavaPluginConvention>().sourceCompatibility = JavaVersion.VERSION_1_8

[araqnid]

a good reference, no, I had to figure this out by noodling around

[Florian Wiesner]

ok, let me give it a try 🙂

[araqnid]

there is a "withConvention" extension function intended to be used on any object that implements hasConvention (e.g. source sets etc, not just projects)

[araqnid]

which I used like this:

val SourceSet.scala: SourceDirectorySet
    get() = withConvention(ScalaSourceSet::class) { scala }

[Florian Wiesner]

well, I’m working with extensions, not conventions

[araqnid]

I got the impression they were mixed together

[Florian Wiesner]

conventions are the older concept

[Florian Wiesner]

and are replaced by extensions over tome

[Florian Wiesner]

time

[Florian Wiesner]

which is why I’m implementing an extension

[araqnid]

the DSL plugin typically uses "extension" to mean Kotlin extension functions, though

[Czar]

Just use plugins {} block instead of buildscript {}, that will generate proper DSL for you, e.g.

plugins {
	java
}
java {
	sourceCompatibility = VERSION_1_8
	targetCompatibility = VERSION_1_8
}

[Florian Wiesner]

ha - seems there is a problem with the test runner…

[araqnid]

there is an ExtensionContainerExtensions.kt in the DSL plugin to allow you to write extensions["xxx"] etc

[araqnid]

ah, right, so things like reporting are project extensions

[Florian Wiesner]

weird one:

plugins {
     id("info.florian-wiesner.magicdraw")
}

[Florian Wiesner]

it is found

[Florian Wiesner]

but…

[Florian Wiesner]

the<florianwiesner.gradle.magicdraw.MagicDrawExtension>() leads to an unresolved reference

[Florian Wiesner]

will dig deeper - thanks @araqnid

[araqnid]

is your extension registered with a name? if so, as Alexander said, it should have been added to the generated glue so you can just refer to it by name

[araqnid]

you can also just call extensions.findByType(ReportingExtension::class.java) which that should be sugar for

[Florian Wiesner]

well, I have a plugin descriptor under META-INF

[Florian Wiesner]

and I currently try gettings things work under Gradle’s test kit

[Florian Wiesner]

using Spek as my test framework

[Florian Wiesner]

my dynamic test script uses the plugins{} DSL

[Florian Wiesner]

and I see the plugin to get loaded

[araqnid]

don't you have to call something from the plugin method to register the project extension?

[Florian Wiesner]

class MagicDrawGradlePlugin : Plugin<Project> {
    private lateinit var project: Project

    override fun apply(project: Project?) {
        if (project == null) throw GradleException("project must not be null")
        this.project = project
        val extension = addExtension<MagicDrawExtension>("magicdraw", project.objects)

        val verifyMagicDrawTask = project.tasks.create("verifyMagicDraw", VerifyMagicDrawTask::class.java)
        verifyMagicDrawTask.installDir = extension.installDir as String? ?: ""
    }

    private inline fun <reified T> addExtension(name: String, vararg args: Any): T = project.extensions.create(name, T::class.java, *args)

}

[Florian Wiesner]

let me make a snippet

[araqnid]

right, so it's registered as magicdraw

[araqnid]

so you should be able to write magicdraw { ... } in the build script, and the glue should have made a Project.magicdraw extension property

[Florian Wiesner]

magicdraw{...} is there

[Florian Wiesner]

but the installDir property is not recognized

[araqnid]

that's a property of the task or the extension or both?

[Florian Wiesner]

both

[araqnid]

are you running the test from IntelliJ or Gradle command-line? I had trouble running this kind of test from IntelliJ

[araqnid]

with it using old versions of the classes under test

[Florian Wiesner]

in the apply function I copy the property value over to the newly created task

[Florian Wiesner]

I run it from gradle

[araqnid]

you copy it from the project extension to the task at the time the plugin is applied? that sounds a bit fishy

[Florian Wiesner]

I wonder whether the test framework GradleRunner supports Kotlin DSL

[Florian Wiesner]

this is just a trial so far

[Florian Wiesner]

and btw, that’s even done in the Gradle docs, when a task is auto-generated from the plugin

[araqnid]

I suspect that if it didn't, you encounter problems much earlier

[Florian Wiesner]

and I see a big issue

[araqnid]

ah? hmm, I should really get more acquainted with those

[Florian Wiesner]

well, how would you generate a default task definition without having the plugin code do so? 😉

[araqnid]

so what happens when the build file changes the settings in the extension object?

[Florian Wiesner]

anyway… plugins{id()...)} finds my plugin and loads it

[Florian Wiesner]

but the script cannot find my classes

[Florian Wiesner]

imports fail

[Florian Wiesner]

so, I guess that the test runner only sees the proxies

[Florian Wiesner]

but not the plugin classes

[Florian Wiesner]

plugins{...} might work because it is somewhat separated from the rest of the script

[Florian Wiesner]

which is why

val fooVersion:String by extra
plugins {
  id("bar") version fooVersion
}

won’t work

[araqnid]

yes, plugins{} has to be right at the top iirc

[Florian Wiesner]

from a Gradle script perspective yes

[Florian Wiesner]

it has to be the first element after buildscript

[araqnid]

well, using plugins{} should replace buildscript{} entirely

[Florian Wiesner]

but Kotlin could of course to things ahead of the plugins block

[Florian Wiesner]

tell that to the JUnit platform guys..

[Florian Wiesner]

I will investigate and update this thread

[araqnid]

kotlin-dsl aiui must grab the set of plugins, use that to generate the "glue" project class with all the extensions/conventions in and then compile the script with an instance of the glue project as receiver

[araqnid]

(you can see the "glue" class if you ctrl+click on sth like "java" or "reporting" in a build.gradle.kts)

[Florian Wiesner]

guess that’s option-B on my keyboard

[Florian Wiesner]

but really, I assume there is breakage in the test runner

[araqnid]

something like that

[Florian Wiesner]

I will test publish the plugin to MavenLocal()

[Florian Wiesner]

and then have a standalone project use it

[araqnid]

I'm trying it here, but even explicitly requesting the extension I'm creating by name isn't working so ...

[Florian Wiesner]

I have to leave for dinner. Will look into it tomorrow and update the thread

[Florian Wiesner]

thanks so far!

[araqnid]

hmph, yes, I can register a project extension and it seems to work when referenced entirely separately, but not when trying to use GradleRunner

[araqnid]

the "glue" class is written to somewhere like /tmp/.gradle-test-kit-shaslam/caches/4.5/gradle-kotlin-dsl-accessors -- i tried just removing the caches, no change

[araqnid]

but that generated class doesn't specify the type of my project extension, the extension property is type Any

[araqnid]

so it seems lined up with the problem you're seeing of not finding the classes in the build script?

[araqnid]

it writes in a comment above the extension property that the named class is not available -- so it knows what the type should be, it just couldn't load it

[araqnid]

/**
 * Configures the [webpack][com.timgroup.gradle.webpack.WebpackProjectExtension] project extension.
 *
 * `webpack` is not accessible in a type safe way because:
 * - `com.timgroup.gradle.webpack.WebpackProjectExtension` is not available
 */
fun Project.`webpack`(configure: Any.() -> Unit): Unit =
    extensions.configure("webpack", configure)

[araqnid]

but publishing to mavenLocal, and pulling it into another project generates the glue class fine ¯\_(ツ)_/¯

[araqnid]

same result with Gradle 4.6. There is also a #C19FD9681 btw 😉

[Florian Wiesner]

ah thanks

[mkobit]

saw the post in #C19FD9681 - this sounds similar to https://github.com/gradle/kotlin-dsl/issues/492