Migrate to Gradle Kotlin DSL

[dbaelz]

What type of PR is this? (check all applicable)

• Refactor
• Feature
• Bug Fix
• Documentation Update

Description

Minor Documentation Change

Update the link to the "licensing" page in the README.

Migration to Gradle Kotlin DSL

The Kotlin DSL has some advantages as described in the documentation (e.g. enhanced editing experience in supported IDEs, with superior content assist, refactoring [...]). Everything should work as before, but features like auto-completion in the build scripts are now supported. Furthermore, I added the buildSrc directory, which is the Gradle way to share/abstract imperativ logic, config and so on for build scripts.

The migration is finished, but the build scripts can be improved even more. For example, all version declaration of dependencies could be moved to buildSrc. I didn't changed that because it's optional and I didn't want to make this decision for the project. With #40 another PR changes the build scripts. I will integrate these changes when this PR is merged before mine.

Feel free to ask questions or challenge my changes. I hope the migration to the Kotlin DSL is accepted for the project and this PR will be integrated.

[optional] What gif best describes this PR or how it makes you feel?

[CLAassistant]

All committers have signed the CLA.

[sierisimo]

This is so awesome! I haven't tried the kotlin DSL in an Android Project but in a kotlin project it's really good. Great PR

[maestromac]

Thanks for this @dbaelz !

I took a peak at Kotlin DSL and I'm totally for it. Regarding the buildSrc, what's the benefit of moving all version declaration of dependencies to buildSrc?

I'll merge this as soon as merge conflict is resolved.

[sierisimo]

I took a peak at Kotlin DSL and I'm totally for it. Regarding the buildSrc, what's the benefit of moving all version declaration of dependencies to buildSrc?

There's not mucho of the changes of adding buildSrc in this PR but the advantage is that you will have all the versions and string constants in one place, also if the building process require some complex step like copying or editing classes in compilation time, it can be achieved in Kotlin code in classes in buildSrc instead of doing patches and hacks on the build.gradle.kts

Also the buildSrc is compiled BEFORE everything so you can add anything that's needed for the building process in it.

But right now… there's no need.

[sierisimo]

Heres is an example of it:

There's also de posibility of writing custom tasks for the building process, like pushing changes to somewhere, run custom rules for validation of code, etc. All the steps implied in the building process and quality checks of your code can be achieved programatically in the buildSrc

This will be helpful if we are on the need of adding more modules that hold common dependencies

[dbaelz]

Thanks @sierisimo you summed it up faster quit well.

The idea (general and in this project) is to avoid redundant information in multiple modules like app, baseui and data. This lowers the risk of bugs due different versions in different modules. It isn't a huge advantage for these simple build scripts, but it's really great if the scripts are more extensive.

We could go even further and for example move parts of the app configuration like "base dependencies" (all dependencies that are redundant defined in all modules) into buildSrc. But for such compact scripts this might be overkill.

I'll updated the PR and integrated the changes of #40. Due the renaming of the scripts files I had to readd the changes to the Kotlin build scripts.

[maestromac]

👍