Customize build directory for composite projects - how to?

Help/Discuss
21

Thanks for the first, but the seccond stills do not compile. The whole code is:

Of course it does not.
I already explained why and three ways to fix it.
You are not configuring the task called run but you are calling this Kotlin stdlib function: run - Kotlin Programming Language

Either do

tasks.run.configure { doFirst { /* ... */ } }

or

tasks.run.configure { doFirst { /* ... */ } }

or

import kotlin.run as stdlib_run
tasks.run { doFirst { /* ... */ } }

or as bonus

import org.gradle.kotlin.dsl.run as runTask
tasks.runTask { doFirst { /* ... */ } }

Also always have a look at the IDE type hints:
image

Error: --module-path requires module path specification

That’s most probably because you apply the JavaFX plugin in its current state which among other bad things applies the org.javamodularity.moduleplugin which is not really a good match with the Gradle-included JPMS support. For more information see for example Allow excluding thirdPartyCompatibility from GMM · Issue #26144 · gradle/gradle · GitHub and especially the comments by @jendrik, and also his PR Use Gradle's variant-aware dependency management and allow using Gradle's built-in Java Module System support by jjohannes · Pull Request #151 · openjfx/javafx-gradle-plugin · GitHub where he fixes the mess. This PR was merged 3 hours ago, so you could try with a snapshot version of the plugin whether it fixes your problems.

1 Like
22 
tasks.run.configure {

Hell, this is what you meant…ok, now I know.

And thanks for the hint to the work from jjohannes. The whole JavaFX stuff is really a mess and controlsfx beats it in different worse kinds, very good that somebody did that work and turned this in a better usable way (even I still hate JavaFX and think about to change to another gui tool set).

23

Hell, this is what you meant…ok, now I know.

I’m honestly curious.
How could you have misunderstood?
I wrote it literally before already:

image
image775×271 27.7 KB

24

Hm…if I read this again, I’m too.
Sorry that I missed this, must be the result of a mix of lack of concentration and some frustration about gradle. I hope you does not misunderstood that as contempt.

1 Like
25

I roamed about some git and gradle pages to get an idea how the fix works, but I still have no idea what to do now.
The most easy thing was to update the openjfx plugin to v0.1.0, I think I get it, but what to do now with it?

Until now, I ignored the module system, as I started the project with Java 8 some years ago, the module system came later with Java 9. That’s why I

application {
	applicationDefaultJvmArgs = listOf("--add-opens", "java.base/java.util=ALL-UNNAMED")
}

because I started without and had no need to modularize anything later. After reading something about the module system - I did never care about that - it is not clearer for me. jjohannes and other guys often write about some metadata rules, is it meaningfull here or am I wrong here?

26

Am I right that the plugin does overwrite the module-info.java file?

27

You should not need to do anything and should be able to even remove that --add-opens line.
JPMS is good and you should really consider using it if you are not bound to Java 8.
It improves JAR hell and introduces some stricter encapsulation of libraries on a systematic level.

As you upgraded the OpenJFX plugin to 0.1.0, you are not automatically using the2 org.javamodularity.moduleplugin anymore which interferes with the built-in JPMS support and you should most probably not get that error anymore that the --module-path option is used without anything put to the module path.

And no, the JavaFX plugin does not overwrite any module-info.java file.

28

It would be very nice if it works and I do not need to do anything…now I know why I searched any how-to-use-docu for no result.

After reading something about it, it may be great, but I do not need it. Nevertheless, I just started with Java 8 but switched to a higher version later. Not sure abou it, but I think it is on Java 16 now.