https://gradle.com/ logo
Join Slack
Powered by
I'm migrating a moderately complex `build.gradle` ...
# community-support
r
I'm migrating a moderately complex 
build.gradle
to 
build.gradle.kts
. The file has been going for 14 years, so there's the inevitable layers of fine-then-bad-practice-now stuff. I'm wondering how best to prove I have migrated all the tasks and logic identically. In an ideal world I could export the configured model for all the tasks, I guess, and check it hadn't changed. Does anyone have any tips on implementing such a test? It feels very 20th century to just leap in, start changing things and hope I spot what breaks - some of these tasks are run rarely.
a
What languages are in the project, just Java? How many subprojects are there?
r
Just Java. There 3 subprojects but I'm not really fussed about them, they are examples really, they don't produce production artifacts.
a
Broadly speaking, the only important tasks will output files into the 
build/
directory. So you could checkout the project twice: one with the Groovy DSL and another with Kotlin DSL. For each task, run 
gradle fooTask
against each project, then verify the 
build/
dir has the same content.
It doesn't have to be a big-bang do-it-all-in-one-go refactor. You could create a buildSrc convention plugin in Kotlin DSL and slowly extract & convert pieces out.
r
I can compare bits and pieces all over the place, but it's I suppose I was hoping for something more scientific & closely focussed on what has been configured in gradle, rather than what outputs result.
I want to do it fairly big-bang because the motivator is to use modern gradle techniques to start splitting up the codebase.
a
yeah, unfortunately I've never heard of a way of 'dumping' the Gradle project model - It would be convenient. Maybe something would be possible with declarative Gradle.
you can dump the generated Kotlin DSL accessors (
./gradlew kotlinDslAccessorsReport
), but that will only reflect the 'public api' of the applied plugins, and not verify the build logic.
maybe https://github.com/gradle/gradle-trace-converter could help - but again, it's not what you're asking for. It'd only be useful for verifying the task graph is the same.
r
That would be useful, thanks. I'll probably need to do some cleaning up of the task graph anyway, I'm sure Vampire would pick all the 
dependsOn
and 
finalizedBy
in it to pieces.
😆 1
a
v
I'm sure Vampire would pick all the 
dependsOn
and 
finalizedBy
in it to pieces.
🤷‍♂️ 🙂
yeah, unfortunately I've never heard of a way of 'dumping' the Gradle project model - It would be convenient.
Wouldn't that be the configuration cache entry? Not really a way to compare those though of course 😄
r
Should anyone be at a loose end and want to contribute to improving the build: https://github.com/wiremock/wiremock/blob/v4.x/build.gradle.kts At time of writing there are 18 calls to 
Provider.get()
, which seems icky. 4 unchecked casts. It's currently a pretty direct port of the old build.gradle: https://github.com/wiremock/wiremock/blob/2ce40503ad90d204f23d26a4dca0deb990d4cd4c/build.gradle
👍 1
a
it looks like an accurate translation to me
5 Views
Open in Slack
PreviousNext
Powered by