Kotlin DSL and TestKit

I would appreciate if anybody from the Kotlin DSL team could have a look at https://github.com/ddimtirov/codacy-gradle-plugin/tree/kotlin-gradle-4.1

It implements a plugin entirely on Kotlin and is pulling together many of the examples from the kotlin-dsl repo, plus thins which I’m trying to figure out. It also fails tests with strange errors.

For Gradle 4.1, the test fails 2 cases with errors that certain providers were not satisfied, even though they should have been, one cases passes.

For Gradle 4.2, the test fails 2 cases with error “class not found groovy/util/AntBuilder” and one case fails with “not being able to resolve property setter”.

I’ll keep talking with myself in case anybody hits the same issues later:

  • The “not being able to resolve property setter” was caused by putting @Option annotation on the property getter - should be on the setter. In other words, the correct way to declare an optional property acccpting settings from cmdline is:

      @set:Option(option="commit-uuid", description="Commit UUID used by Codacy to track the current results. Typically inferred from the environment.")
      @get:Optional @get:Input 
      var commitUuid by commitUuidState
    

    Be careful to choose the right @get: vs @set: on each annotation.

  • Regarding the “class not found groovy/util/AntBuilder” - turns out it is caused by the JaCoCo plugin in the test build. For some reason, the test build does not have the ant builder in its classpath and JaCoCo fails as it uses the Ant tasks internally.

I am still not sure why is the TestKit running with incomplete classpath, but I will try tomorrow manually adding Ant as buildscript dependency.

The AntBuilder classpath error was caused from using GradleRunner.withDebug(true) - it is a known issue and it looks like it is not easy to address.

Next problem was that the worker fails with NPE when any of the WorkerConfiguration::params is null - missing null check in the code determining the argument types.

I had to introduce a dummy default value and then check for it, rather than relying on the Kotlin’s ?: construct…

Giving up for the time being - this is not supposed to be so difficult.

Going to wait until Kotlin support is officially ready for testing.