Closed sdavids closed 4 years ago
The somewhat unique challenge in this plugin is that versionNext/Last = f(changelogFile, ifFoundBump...)
, and that function gets executed during buildscript evaluation - before task execution. So it's really important to error loudly and clearly if any of those inputs are changed after they have been used to evaluate versionNext
, which we enforce using this construction. This design is bad practice in general, but this plugin fits in a very unique spot. Luckily, I have not yet found a situation where my spotlessChangelog
plugin depends on anything else, so it's easy to just put it at the top of my scripts.
I initially tried to implement the plugin DSL in terms of lazy properties, but they seem tailored to values which aren't used until task execution, but we need something for script evaluation. It's possible that there is a way to do it, but I was not able to figure it out, and the way it is implemented currently is pretty straightforward to read and understand.
Happy to take a PR which improves the aesthetics of the Kotlin DSL, whether it uses lazy properties or not. I would be hesitant to merge something which makes the "immutable once calculated" logic harder to read. I would not be hesitant to merge whatever getX/setX
boilerplate is necessary for Kotlin to look better, but I would like a testcase which proves that Kotlin "looks nicer" with the changes - in general I think minimal code > using all available conventions, but I'm always open to improvements for users who can show that the changes improve their own real usecase.
Happy to review a PR against this issue if anyone has a way to implement, but I'm closing due to "unlikely to be implemented".
Compared to the Gradle-DSL the Kotlin-DSL does not really look "nice":
Maybe use lazy properties?
https://docs.gradle.org/current/userguide/lazy_configuration.html