Open eskatos opened 7 years ago
I think this is more important with the introduction of Property
and PropertyState
types in Gradle core with the desire to not create a bunch of cruft in the Kotlin DSL. That is unless those are going to be used directly as task inputs or outputs in the future.
Should the Property.set
versus Groovy DSL decoration to work for =
be split out in a different issue?
The issue was broken down further and the Java interop aspect, more relevant to us, extracted to KT-24831 so it could be fixed sooner.
The Gradle API rely a lot on overloaded setters. Kotlin support for such constructs and proper integration with Java declarations would make for a nicer DSL.
https://youtrack.jetbrains.com/issue/KT-4075