Why should you choose Groovy over Kotlin

Gradle: Let the DSL plugin extend the properties as part of the version

Thank you everyone for your comments on this matter and for your patience while you wait for some action.

We spent some time researching this issue and considered a number of possible fixes.

1. Allow properties to be substituted for version strings in the block

This seems easy and would ensure consistency with the number of users maintaining the version of their regular code dependencies. However, the approach is more problematic than it initially appears.

Plugin versions differ from regular dependencies in that they affect the classpath that is used to compile and run Gradle build scripts. Gradle does extensive caching of both the script class path and the compiled scripts. This caching does not currently take any properties or environment variables into account. A first attempt to allow properties to be replaced in version strings was therefore unsuccessful: Changes to the properties file were ignored due to the caching of the compiled build scripts. While it is possible to make cache invalidation smarter, we want to be careful not to degrade performance by doing it too aggressively (especially with Kotlin build scripts, where compile time is significant).

In summary, replacing properties in strings of the plugin version is straightforward, but caching compiled build scripts is more problematic.

2. Make the block reference constants that are in

The implementation of is very different for the Groovy and Kotlin DSLs. For Groovy, we implemented AST transforms to extract the information during a script compilation on the first pass (the code is never called). For Kotlin we instead constrain the inputs and call the code in the block (I'll admit, I don't quite understand how this works).

In order for the Groovy DSL to act more like the Kotlin DSL, we would likely have to reimplement the script compilation of the former to become more similar to the latter. This may be a worthwhile exercise, but defining constants in more of a workaround for the lack of property substitution and has the disadvantage of invalidating your entire build script when a version changes.

In summary: In order to access constants / code in the block, the mechanism for loading Groovy scripts has to be revised considerably.

3. Define plug-in versions as dependencies

This mechanism works in current versions of Gradle and can be very effective for centrally managing plugin versions. Basically, you add the plugin as a dependency on your root project, and the plugin can then easily be applied via ID from your build scripts.

buildSrc / build.gradle


A disadvantage of this approach is that you need to know both the GAV and the plugin ID for the plugin you requested. (Note the difference between and).

In summary: Dependencies can be used to centrally manage the plugin versions, but it seems like a step back to the old dependency declarations.

4. Define plugin versions within

Ideally, the required plugin versions are defined in a central location so that the plugins can be used in every build script based on the ID. Gradle 5.6 offers this functionality, whereby plugin versions are configured in the Gradle settings block.

settings.gradle [.kts]

build.gradle [.kts]

The new block does not have the same restricted syntax as a Buildscript block and allows flexible versioning by replacing properties, version constants, etc.
In addition, this mechanism offers advantages over dependencies:
a) it does not require a project and
b) The GAV for the plug-in artifact is not required.

In summary, we believe this new mechanism eliminates the need for the block to allow for more flexible syntax or property substitution.

Feedback is welcome

If you voted for or commented on this topic, we would love to hear from you. Does the new block give you the functionality you need? Would it be okay if we close this problem and provide the block as a solution? Please inform us.