Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

run error in jpms and gradle 6.6 #89

Closed
makhocheung opened this issue Aug 22, 2020 · 12 comments · Fixed by #98
Closed

run error in jpms and gradle 6.6 #89

makhocheung opened this issue Aug 22, 2020 · 12 comments · Fixed by #98

Comments

@makhocheung
Copy link

makhocheung commented Aug 22, 2020

My demo project uses gradle 6.6 , jpms structruce and javafxplugin 0.0.9. When I run then run task, an error occurs as follow

> org.joor.ReflectException: java.lang.NoSuchFieldException: javaExecHandleBuilder

If I change the gradle version to 6.5 or remove the module-info.java, the run task works fine

@makhocheung
Copy link
Author

I found the reason because of the plugin org.javamodularity:moduleplugin:1.7.0

@makhocheung
Copy link
Author

Refer to https://docs.gradle.org/current/userguide/application_plugin.html#sec:application_modular. Gradle has supported JPMS. So Can the javamodularity:moduleplugin be removed?

@jperedadnr
Copy link
Collaborator

@utybo
Copy link

utybo commented Aug 26, 2020

Can confirm that this is affecting me as well and makes the JavaFX plugin unusable for Gradle 6.6+. Any workarounds?

@makhocheung
Copy link
Author

makhocheung commented Aug 27, 2020

@utybo Here is a simple way to configure a module JavaFx project in Gradle 6.6.
1

java {
    modularity.inferModulePath.set(true)
}

2

application{
    mainModule.set($moduleName)
    mainClass.set($mainClass)
}

3

dependencies {
    val jfxOptions = object {
        val group = "org.openjfx"
        val version = "14.0.2.1"
        val fxModules = arrayListOf("javafx-base","javafx-controls","javafx-graphics","javafx-media","javafx-swing")
    }
    jfxOptions.run {
        val osName = System.getProperty("os.name")
        val platform = when {
            osName.startsWith("Mac", ignoreCase = true) -> "mac"
            osName.startsWith("Windows", ignoreCase = true) -> "win"
            osName.startsWith("Linux", ignoreCase = true) -> "linux"
            else -> ""
        }
        fxModules.forEach {
            implementation("$group:$it:$version:$platform")
        }
    }
}

You can also see here

@jchildress
Copy link

Any update on this? I'm getting the same "error"...

org.joor.ReflectException: java.lang.NoSuchFieldException: javaExecHandleBuilder

@xzel23
Copy link

xzel23 commented Mar 6, 2021

Ok, so I looked into this again because I want to try building JavaFX applications on JDK 16. This will require Gradle 7. I saw that this plugin has a dependency on a plugin to help with the module system (org.javamodularity.moduleplugin). This won't be needed on Gradle 7+ because Gradle 7 will come with full support for Jigsaw modules.

So I have forked this module on Github to experiment with this, and now I have a working plugin for Gradle 7/JDK 16 that runs my example project perfectly fine.

If anyone is interested in trying it out, please let me know. I think it might not (yet?) be a good idea to merge back into upstream because it will break things for those using older Gradle versions.

@bjonnh
Copy link

bjonnh commented Mar 11, 2021

I would like to give it a try. I need to build an application for both windows and Linux and it is quite painful… I was trying to switch to github actions to build them remotely but I keep hitting on different issues. Now it is the:

> Failed to apply plugin class 'org.javamodularity.moduleplugin.ModuleSystemPlugin'.
   > Could not create task ':run'.
      > Replacing an existing task that may have already been used by other plugins is not supported.  Use a different name for this task ('run').

@xzel23
Copy link

xzel23 commented Mar 22, 2021

@bjonnh: my Gradle 7 compatible fork of the plugin is at https://github.com/xzel23/javafx-gradle-plugin. I have also just submitted it for inclusion in the Gradle plugin catalogue, but it's still pending approval. I will leave a comment here if it is available via the standard Gradle plugin repository. I have tested it with Gradle 7 Milestone 3 and JDK 16.

@xzel23
Copy link

xzel23 commented Mar 22, 2021

The forked plugin for Gradle 7 is now available. I hope it works for you. If it doesn't, remember not to report issues here but in the fork. If I find the time, I might at some later time try to find a solution that doesn't break builds on Gradle 6 and could be applied upstream.

@patilnikhilh80
Copy link

Ok, so I looked into this again because I want to try building JavaFX applications on JDK 16. This will require Gradle 7. I saw that this plugin has a dependency on a plugin to help with the module system (org.javamodularity.moduleplugin). This won't be needed on Gradle 7+ because Gradle 7 will come with full support for Jigsaw modules.

So I have forked this module on Github to experiment with this, and now I have a working plugin for Gradle 7/JDK 16 that runs my example project perfectly fine.

If anyone is interested in trying it out, please let me know. I think it might not (yet?) be a good idea to merge back into upstream because it will break things for those using older Gradle versions.

I used your fork in my project but I am getting error
src\main\java\module-info.java:6: error: module not found: jettison
requires jettison;

Do I need to change some configuration to add this dependancy?

@xzel23
Copy link

xzel23 commented Apr 19, 2021

@patilnikhilh80 This looks like a problem with your build that has nothing to do with the gradle plugin. I have never used jettison, so I looked for the project on github. At first glance, it seems not to offer any support for the module system, not even an automatic module name. If that's right, please open an issue with the jettison maintainers to request module support.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants