It seems that it is really related to the way the ...

# gradle

[bjonnh]

It seems that it is really related to the way the kotlin plugin compiles kotlin code and uses the module information.

[tapchicoma]

Kotlin plugin will support Gradle 7 starting from 1.5.0-M2 release

[bjonnh]

oh great, thanks for the heads up

[tapchicoma]

if you will something not working, please add a comment to this issue: https://youtrack.jetbrains.com/issue/KT-44949

[bjonnh]

I think we (or just I) may want to document how to make modular programs with Kotlin, many of the tricks are not limited to Kotlin but I'm sure that would be helpful.

[bjonnh]

I got everything to work with 7.0 I just had to use a module-info.java generator plugin.

[tapchicoma]

I think we (or just I) may want to document how to make modular programs with Kotlin, many of the tricks are not limited to Kotlin but I'm sure that would be helpful.

Would be nice 👍

If you will found something is missing in Kotlin for better modules support - please open a new issue.

[Javier]

I am using Gradle 7.0 since Kotlin... 1.4.20 I think, with no issues.

[Javier]

What should not work @tapchicoma?

[tapchicoma]

@Javier 1.4.20 was released before G7-milestone-1 🤔

Anyway KGP will try to use several removed configurations, removed old workers api and few other things that should break the build with Kotlin

[bjonnh]

The other thing I need to do all the time with modular builds is to put the kotlin and java destination dirs to the same one. If not, I have to declare all the packages manually in java using empty classes…

[bjonnh]

(see https://github.com/bjonnh/2021_modules_unnamed_error/tree/using-extra-java-module-info)

[bjonnh]

Let me know if there are ways to avoid doing that or if there is something I am doing wrong here

[bjonnh]

@Javier If you don't use modular builds, yes Gradle 7.0 works well. Just that there are a few things that changed regarding the way modules are handled and I was not using them properly so it started to break in Gradle 7.0

[Javier]

what do you mean which modular builds?

[Javier]

having multiple modules?

[bjonnh]

Java modular build system

[Javier]

Well, in my case I am using multiple modules which Kotlin Multiplatform, so it is not the same and that can be the reason I had no problems

[bjonnh]

not the same "modules"

[bjonnh]

Java is moving slowly to a new way to manage libraries, that allows to build "JREs" that are tailored to your application. So your distributed applications are much smaller.

[bjonnh]

and this is brittle with libraries that didn't move to that new way to advertise themselves (it really mostly take a module-info.java file). So you need plugins that create that for you during the build.

[Vampire]

The other thing I need to do all the time with modular builds is to put the kotlin and java destination dirs to the same one. If not, I have to declare all the packages manually in java using empty classes…

You should not do that.
Tasks should not have overlapping outputs or you f*** up proper up-to-date checks and build output caching.
"Just" patch your Kotlin output directory into the java compilation task using --patch-module

Something like this should do it properly I think:

tasks.compileJava {
    options.compilerArgumentProviders.add(
        object : CommandLineArgumentProvider {
            @get:Optional
            @get:Classpath
            protected val compileKotlinOutputClasses =
                tasks.compileKotlin.flatMap { it.destinationDirectory }
            override fun asArguments() = listOf(
                "--patch-module",
                "my.foo=${tasks.compileKotlin.get().destinationDir.absolutePath}"
            )
        }
    )
}

[tapchicoma]

@Vampire wow, --patch-modules is not exposed as compileJava task input?

[Vampire]

Where my.foo is the module you are trying to build

[Vampire]

I don't think so

[tapchicoma]

probably interesting issue to read: https://github.com/jjohannes/gradle-jpms-experiments/issues/1

[bjonnh]

@Vampire why would that break anything cache related if I don't have any java code?

[Vampire]

But you have Java code

[bjonnh]

I have two options A) make java/kotlin output dir the same and put module-info.java in my kotlin dir B) create empty packages (which yes I agree will mess everything that's why I don't use it)

[Vampire]

Or option C which I just told you how

[Vampire]

No matter where you put the Java file, it is compiled by the java compile task

[Vampire]

And the kotlin files are compiled by the kotlin compile task

[bjonnh]

Yes but I don't see the advantage compared to option A

[Vampire]

You don't break things?

[bjonnh]

That's a good reason 😉

[Vampire]

If both tasks have output directory "foo", taskA generates "foo/module-info.class" and taskB generates "foo/my/other/clazz/from/kotlin/Bar.class", then if you run both tasks, the second sees the output of the first as own output. Which might make it delete it on full recompilation, store it into the build cache and also restore it from the build cache, be out-of-date if the file changed or was deleted, ...

[Vampire]

In ancient versions Groovy and Java compile tasks compiled to the same destination directory, until the Gradle guys have observed they hit these problems and properly separated the output directories.

[Vampire]

The simple rule is to never have overlapping outputs for multiple tasks.

[bjonnh]

Oh that make sense… Your version seems to work.

[bjonnh]

That's always the thing with gradle… You have to find the people that know the right incantations…

[bjonnh]

thanks!