does anyone have a good, open-source, example of c...

# intellij

[Ben Madore]

does anyone have a good, open-source, example of configuring a non-trivial multi-module build using gradle kotlin-dsl?

[Ben Madore]

i’m struggling to understand how much of what i’ve got is necessary, or what can actually be pulled up to the parent. doesn’t help that it’s always unclear to me how a given gradle plugin operates in multi-module projects. can it be applied/configured only at the top-level? does need to be configured for each project?

[Zach Klippenstein (he/him) [MOD]]

Not sure how non-trivial is non-trivial for you, but there’s https://github.com/square/workflow-kotlin. That said, it’s pretty gross and I would really like to simplify it, e.g. get rid of those extracted groovy scripts that I couldn’t figure out how to port. Hoping someone here has an answer too 😅

[Hanno]

I have done dozens of multi module projects at work, some with groovy dsl, some with kotlin dsl, i even converted groovy dsl scripts of hundreds of lines of gradle code. I think i worked with pretty complex builds, so i think i can help both of you with your problems If you want me to :)

@Ben Madore what is necessary is what gets your job done. Solving complex problems without some experience would sadly most often result in brittle builds, so lets try to look at very concrete problems you have. For example you "can" pull all the logic of all you subprojects into your root, but should you? No. Every project should configure itself more or less. Abstraction and reusability can be achieved through plugins or shared code in buildSrc.

Modules generally apply only to the project you explicitly apply it to. Some exceptions exist though, but i think you wont encounter those normally. So if you use java plugin, apply it in every subproject with the plugins dsl, simple as that. Any more questions? :)

@Zach Klippenstein (he/him) [MOD] what in particular could you need help with? Maybe i can take a look at some constructs and show you the solution :) feel free to pm.

[Ben Madore]

for large projects it makes zero sense imo to configure say:

java {
        sourceCompatibility = JavaVersion.VERSION_11
        targetCompatibility = JavaVersion.VERSION_11
    }

    idea {
        module {
            isDownloadJavadoc = true
            isDownloadSources = true
        }
    }

in each project… perhaps i need to further investigate shared code in buildSrc for plugin configuration

[Hanno]

You could either extract two helper functions to the buildSrc project and call them in your projects. The other option (better when it works for you) would be precompiled script plugins, like here https://docs.gradle.org/current/samples/sample_precompiled_script_plugin.html they let you basically cut n paste your stuff into an ad-hoc plugin, that you can reference as a plugin like any other plugin. When you need java and intellij everywhere, just make one precompiled plugin out of them

[Ben Madore]

well, i DO have this 3 year old comment from myself in the sub-project configuration in the main project:

// TODO: Consider moving this to a precompiled script in buildSrc once it's more mature. mayhap it’s time to reattempt

[Hanno]

Consider moving to gradle 6.6 and use the java release flag feature maybe :D

[Hanno]

If you encounter any other obstacles, feel free to ping

[Ben Madore]

ah, yeah, definitely gonna upgrade, didn’t realize 6.6 was released yesterday