Refactor some build logic to the buildSrc & gradle kotlin-dsl

[jmfayard]

Refactor some build logic to the buildSrc & gradle kotlin-dsl

Files buildSrc/src/main/java/{Versions.kt,Libs.kt} generated by kotlinpoet and the task
$ ./gradlew syncLibs

See https://blog.kotlin-academy.com/gradle-kotlin-the-missing-piece-of-the-puzzle-7528a85f0d2c

[googlebot]

We found a Contributor License Agreement for you (the sender of this pull request), but were unable to find agreements for all the commit author(s) or Co-authors. If you authored these, maybe you used a different email address in the git commits than was used to sign the CLA (login here to double check)? If these were authored by someone else, then they will need to sign a CLA as well, and confirm that they're okay with these being contributed to Google.
In order to pass this check, please resolve this problem and have the pull request author add another comment and the bot will run again. If the bot doesn't comment, it means it doesn't think anything has changed.

[googlebot]

CLAs look good, thanks!

[jmfayard]

Mmh, test PlantTest#test_shouldBeWatered is working on my computer but is failing on CircleCI.
I don't find the artifacts on CircleCi to find out why.
Any help?

[tiembo]

That test is a bit flaky, and #212 should fix it. I manually kicked off a CI re-run.

[XinyueZ]

Wow, pretty same what I want to introduce, thx @jmfayard, however, it is real kotlin special, I like it.

[jmfayard]

@tiembo anyway I have a good grasp now on Gradle's Kotlin DSL.
If that's a topic you are interested in, I can update and improve this pull request.

If not, that's also fine. I used a few projects like yours to make sure that my plugin https://github.com/jmfayard/gradle-kotlin-dsl-libs works correctly, which seems to be the case :)

[XinyueZ]

@jmfayard could you please resolve conflicts, I am personally as one of fans of dsl.

[jmfayard]

@XinyueZ done

[XinyueZ]

@jmfayard I think you need format code 🌦

[jmfayard]

@XinyueZ done.
Nice thing, I will use it to my projects too

[tiembo]

Hi @jmfayard , apologies for the delay in replying.

I like the Kotlin DSL but feel that it's beyond the scope of this Jetpack-focused sample. Happy to note this PR in the README or Wiki as an sample of implementing gradle-kotlin-dsl-libs. Would that work?

[jmfayard]

@tiembo no big problem for me, I needed repositories to test my plugin with anyway, so that part is mission accomplished.

Just for completion, I realize that putting kotlin dsl in the name of my plugin a bit of a misnommer.

I think that writing Gradle builds in Kotlin instead of Groovy is the future, but writing them in Groovy is the present, and I wouldn't actually recommend rewriting any existing build just for the sake of the rewrite. In the end, it's just the same Gradle build.

What I'm instead doing for my own projects (and it's a Gradle best practice by the way)

• Keep the existing build.gradle files, especially the parts in it that are nice and declarative.
• Find the parts from the build files that look like Groovy code, and extract that build logic to that special buildSrc Gradle module. And there I use Kotlin.

[tiembo]

Referenced this PR in the wiki.