search

beryx / badass-jlink-plugin

Create a custom runtime image of your modular application
https://badass-jlink-plugin.beryx.org
Apache License 2.0
379 stars 25 forks source link

Support for Java 15 jpackage #153

Closed nemphys closed 1 year ago

nemphys commented 4 years ago

Trying to run the jpackage task using the JDK binary produces the following error:

Bundler Mac Application Image skipped because of a configuration problem: "Failed to find [xxx.xxx.xxx] module in module path" (where xxx.xxx.xxx => my main module name).

Since the same configuration works just fine with JDK14, I supposed something changed with the parameters required by the new version.

siordache commented 4 years ago

Strange... I'm not able to reproduce the problem with neither this nor this project.

nemphys commented 3 years ago

No idea, but it is definitely there in my case.

PS. I also have the notion that JDK 15 broke the "reproducible builds" feature; after switching to JDK15 jlink, all pseudo-jars that are created for non-modular jars + the merged modules jar are always different than the previous build, even if nothing has changed.

nemphys commented 3 years ago

PS. I also have the notion that JDK 15 broke the "reproducible builds" feature; after switching to JDK15 jlink, all pseudo-jars that are created for non-modular jars + the merged modules jar are always different than the previous build, even if nothing has changed.

After doing some more testing concerning this secondary issue, it seems that it has nothing to do with JDK15 after all; I would like to create a separate issue for it, but I have no idea of how to properly describe it, so maybe you can help me:

My application has a total of 9 modules (+ the merged module created by this plugin and proper modular dependencies), for which I use separate versioning. The whole gradle build setup (and all jlink related properties) lives in the "ui" module's build.gradle file. If I keep all dependencies intact and change the version of any of the application modules except the "ui" module, the jlink delegating modules and the merged module remain exactly the same (= reproducible build).

However, if I change the "ui" module's version, all jlink delegating modules and the merged module have changes (different checksum) and therefore the build is not reproducible. After decompiling and comparing one of the delegating module's jar before and after the above version change, the difference seems to reside in module-info.class. This file should not contain anything related to the "ui" module's version, but just a "open module XXXXX { requires transitive XXXXXX; }" entry, BUT just doing a cat on the (compiled) files, I can see the version of the "ui" module inside the (binary) data, which of course differs.

Any idea why this is happening? Is it by design, or can I somehow avoid it (since it effectively does not allow changing the "ui" module's version without having to replace the whole list of otherwise unchanged dependencies)?

EDIT: I just debugged the gradle build itself and realised that CreateMergedModuleTaskImpl's getVersionOpts() did not find a "version" property in mergedModule configuration (I hadn't set that, since I thought mergedModuleJarVersion was all that was needed), so it used the "main" module's version (= "ui" module's version). I suppose this explains everything (and solves my problem by setting the correct version property).

Maybe you should consider removing the mergedModuleJarVersion altogether and name the jar file according to this mergedModule version property, so that the version is set in one place avoiding confusion.

siordache commented 3 years ago

In 2.22.1 mergedModuleJarVersion and mergedModule.version have the same meaning: they configure both the module version of the merged module and the suffix of its jar name.

However, mergedModuleJarVersion is now deprecated and marked for removal. (I didn't remove it in order to avoid breaking changes.)

If both mergedModuleJarVersion and the version property of the mergedModule block are set, mergedModule.version takes precedence.

nemphys commented 3 years ago

Nice! Thank you for this, now we are left with just this issue...

Siedlerchr commented 3 years ago

When I execute jlink under jdk15 with version 2.22.2 I get the following error on graalvm module: 2.22.1 works fine Task :createMergedModule FAILED

/Users/xxx/workspace/jabref/build/jlinkbase/tmpjars/org.jabref.merged.module/module-info.java:1536: error: module not found: org.objectweb.asm
    requires org.objectweb.asm;
                          ^
/Users/xxx/workspace/jabref/build/jlinkbase/tmpjars/org.jabref.merged.module/module-info.java:1549: error: module not found: com.oracle.truffle.regex
    requires com.oracle.truffle.regex;
                               ^
/Users/xxx/workspace/jabref/build/jlinkbase/tmpjars/org.jabref.merged.module/module-info.java:1553: error: module not found: org.objectweb.asm.util
    requires org.objectweb.asm.util;
                              ^
/Users/xxx/workspace/jabref/build/jlinkbase/tmpjars/org.jabref.merged.module/module-info.java:1555: error: module not found: org.objectweb.asm.commons
    requires org.objectweb.asm.commons;
                              ^
/Users/xxxx/workspace/jabref/build/jlinkbase/tmpjars/org.jabref.merged.module/module-info.java:1556: error: module not found: org.graalvm.truffle
    requires org.graalvm.truffle;
siordache commented 3 years ago

Oh, right, version 2.22.2 was really broken. I now released 2.22.3, which should fix the error.

Siedlerchr commented 3 years ago

Thanks, that works now!

msgilligan commented 3 years ago

I'm seeing this problem with 2.22.3 when I try to enable Dcom.sun.management.jmxremote by adding customImage as follows:

    customImage {
        jdkAdditive = true
        jdkModules = ['java.management','java.instrument','jdk.management.agent','jdk.crypto.ec']   // debug only
    }

I'm adding this to support the below jvmArgs setting:

    launcher {
        name = appName
        jvmArgs = ['-Dcom.sun.management.jmxremote']
    }
siordache commented 3 years ago

@msgilligan What error do you get?

msgilligan commented 3 years ago

Basically the same error as @nemphys -- It can't find my main/application module.

> Task :portfolio-omnimarketcap:jpackageImage FAILED
WARNING: Using incubator modules: jdk.incubator.jpackage
jdk.incubator.jpackage.internal.ConfigException: "Failed to find omnimarketcap module in module path"
        at jdk.incubator.jpackage/jdk.incubator.jpackage.internal.LauncherData.createModular(LauncherData.java:154)
        at jdk.incubator.jpackage/jdk.incubator.jpackage.internal.LauncherData.create(LauncherData.java:115)
        at jdk.incubator.jpackage/jdk.incubator.jpackage.internal.StandardBundlerParam.lambda$static$0(StandardBundlerParam.java:93)
        at jdk.incubator.jpackage/jdk.incubator.jpackage.internal.BundlerParamInfo.fetchFrom(BundlerParamInfo.java:114)
        at jdk.incubator.jpackage/jdk.incubator.jpackage.internal.BundlerParamInfo.fetchFrom(BundlerParamInfo.java:88)
        at jdk.incubator.jpackage/jdk.incubator.jpackage.internal.AppImageBundler.validate(AppImageBundler.java:65)
        at jdk.incubator.jpackage/jdk.incubator.jpackage.internal.Arguments.generateBundle(Arguments.java:679)
        at jdk.incubator.jpackage/jdk.incubator.jpackage.internal.Arguments.processArguments(Arguments.java:549)
        at jdk.incubator.jpackage/jdk.incubator.jpackage.main.Main.execute(Main.java:98)
        at jdk.incubator.jpackage/jdk.incubator.jpackage.main.Main.main(Main.java:52)
jdk.incubator.jpackage.internal.PackagerException: Bundler Mac Application Image skipped because of a configuration problem: "Failed to find omnimarketcap module in module path"
        at jdk.incubator.jpackage/jdk.incubator.jpackage.internal.Arguments.generateBundle(Arguments.java:696)
        at jdk.incubator.jpackage/jdk.incubator.jpackage.internal.Arguments.processArguments(Arguments.java:549)
        at jdk.incubator.jpackage/jdk.incubator.jpackage.main.Main.execute(Main.java:98)
        at jdk.incubator.jpackage/jdk.incubator.jpackage.main.Main.main(Main.java:52)
Caused by: jdk.incubator.jpackage.internal.ConfigException: "Failed to find omnimarketcap module in module path"
        at jdk.incubator.jpackage/jdk.incubator.jpackage.internal.LauncherData.createModular(LauncherData.java:154)
        at jdk.incubator.jpackage/jdk.incubator.jpackage.internal.LauncherData.create(LauncherData.java:115)
        at jdk.incubator.jpackage/jdk.incubator.jpackage.internal.StandardBundlerParam.lambda$static$0(StandardBundlerParam.java:93)
        at jdk.incubator.jpackage/jdk.incubator.jpackage.internal.BundlerParamInfo.fetchFrom(BundlerParamInfo.java:114)
        at jdk.incubator.jpackage/jdk.incubator.jpackage.internal.BundlerParamInfo.fetchFrom(BundlerParamInfo.java:88)
        at jdk.incubator.jpackage/jdk.incubator.jpackage.internal.AppImageBundler.validate(AppImageBundler.java:65)
        at jdk.incubator.jpackage/jdk.incubator.jpackage.internal.Arguments.generateBundle(Arguments.java:679)
        ... 3 more

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':portfolio-omnimarketcap:jpackageImage'.
> Process 'command '/Users/sean/.sdkman/candidates/java/15.0.1.hs-adpt/bin/jpackage'' finished with non-zero exit value 1

Sorry for not responding sooner.

siordache commented 3 years ago

The customImage block was not compatible with jpackage. I fixed this in 2.23.1.

nemphys commented 3 years ago

Any news on this one? The customImage block change had no effect (I have been using the customImage block along with jpackage since forever, btw, and it works fine with jpackage versions < 15). Furthermore, I just updated the JLink plugin to the latest version and it now fails even with jpackage 14... Some kind of regression maybe? The new error (with jpackage 14, that used to work up until 2.22.2) is: "Input directory specified is not a directory: /xxx/build/image/app"

siordache commented 3 years ago

@nemphys What error do you get when using jpackage 16?

nemphys commented 3 years ago

Hoping you meant jpackage 15, the error is the same (the one on the initial description of this issue). Looks like the changes you made were not relevant to this specific problem.

siordache commented 3 years ago

No, I really meant jpackage 16. You can download an Early-Access Build and use one of the methods described here to configure your project to use the jpackage tool from this distribution.

nemphys commented 3 years ago

OK, will try that tomorrow, but I wonder why you want to test this. Is there a change in v.16?

siordache commented 3 years ago

They fixed a couple of bugs in jpackage 16. I'm curious if you get the same error.

Also, when testing with jpackage 16, please add the --verbose option:

jlink {
    ...
    jpackage {
        ...
        imageOptions += '--verbose'
        installerOptions += '--verbose'
    }
}

Then, run gradle with the -i option and post here the output of the jpackageImage and jpackage tasks.

nemphys commented 3 years ago

Nothing changes with jpackage from JDK 16, here is the log:

Task :ui:jpackageImage FAILED [17:49:27.023] java.nio.file.NoSuchFileException: /Users/xxxx/git/java/xxxx/ui/build/image/xxxxx/release at java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:92) at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:106) at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:111) at java.base/sun.nio.fs.UnixFileSystemProvider.newByteChannel(UnixFileSystemProvider.java:219) at java.base/java.nio.file.Files.newByteChannel(Files.java:375) at java.base/java.nio.file.Files.newByteChannel(Files.java:426) at java.base/java.nio.file.spi.FileSystemProvider.newInputStream(FileSystemProvider.java:420) at java.base/java.nio.file.Files.newInputStream(Files.java:160) at java.base/java.nio.file.Files.newBufferedReader(Files.java:2916) at java.base/java.nio.file.Files.newBufferedReader(Files.java:2948) at jdk.jpackage/jdk.jpackage.internal.LauncherData$ModuleInfo.fromCookedRuntime(LauncherData.java:365) at jdk.jpackage/jdk.jpackage.internal.LauncherData.createModular(LauncherData.java:149) at jdk.jpackage/jdk.jpackage.internal.LauncherData.create(LauncherData.java:115) at jdk.jpackage/jdk.jpackage.internal.StandardBundlerParam.lambda$static$0(StandardBundlerParam.java:84) at jdk.jpackage/jdk.jpackage.internal.BundlerParamInfo.fetchFrom(BundlerParamInfo.java:114) at jdk.jpackage/jdk.jpackage.internal.BundlerParamInfo.fetchFrom(BundlerParamInfo.java:88) at jdk.jpackage/jdk.jpackage.internal.AppImageBundler.validate(AppImageBundler.java:66) at jdk.jpackage/jdk.jpackage.internal.Arguments.generateBundle(Arguments.java:663) at jdk.jpackage/jdk.jpackage.internal.Arguments.processArguments(Arguments.java:538) at jdk.jpackage/jdk.jpackage.main.Main.execute(Main.java:98) at jdk.jpackage/jdk.jpackage.main.Main.main(Main.java:52) [17:49:27.028] jdk.jpackage.internal.ConfigException: "Failed to find xx.xxxxxxx.xx.ui module in module path" at jdk.jpackage/jdk.jpackage.internal.LauncherData.createModular(LauncherData.java:154) at jdk.jpackage/jdk.jpackage.internal.LauncherData.create(LauncherData.java:115) at jdk.jpackage/jdk.jpackage.internal.StandardBundlerParam.lambda$static$0(StandardBundlerParam.java:84) at jdk.jpackage/jdk.jpackage.internal.BundlerParamInfo.fetchFrom(BundlerParamInfo.java:114) at jdk.jpackage/jdk.jpackage.internal.BundlerParamInfo.fetchFrom(BundlerParamInfo.java:88) at jdk.jpackage/jdk.jpackage.internal.AppImageBundler.validate(AppImageBundler.java:66) at jdk.jpackage/jdk.jpackage.internal.Arguments.generateBundle(Arguments.java:663) at jdk.jpackage/jdk.jpackage.internal.Arguments.processArguments(Arguments.java:538) at jdk.jpackage/jdk.jpackage.main.Main.execute(Main.java:98) at jdk.jpackage/jdk.jpackage.main.Main.main(Main.java:52) [17:49:27.034] jdk.jpackage.internal.PackagerException: Bundler Mac Application Image skipped because of a configuration problem: "Failed to find xx.xxxxxxx.xx.ui module in module path" at jdk.jpackage/jdk.jpackage.internal.Arguments.generateBundle(Arguments.java:680) at jdk.jpackage/jdk.jpackage.internal.Arguments.processArguments(Arguments.java:538) at jdk.jpackage/jdk.jpackage.main.Main.execute(Main.java:98) at jdk.jpackage/jdk.jpackage.main.Main.main(Main.java:52) Caused by: jdk.jpackage.internal.ConfigException: "Failed to find xx.xxxxxxx.xx.ui module in module path" at jdk.jpackage/jdk.jpackage.internal.LauncherData.createModular(LauncherData.java:154) at jdk.jpackage/jdk.jpackage.internal.LauncherData.create(LauncherData.java:115) at jdk.jpackage/jdk.jpackage.internal.StandardBundlerParam.lambda$static$0(StandardBundlerParam.java:84) at jdk.jpackage/jdk.jpackage.internal.BundlerParamInfo.fetchFrom(BundlerParamInfo.java:114) at jdk.jpackage/jdk.jpackage.internal.BundlerParamInfo.fetchFrom(BundlerParamInfo.java:88) at jdk.jpackage/jdk.jpackage.internal.AppImageBundler.validate(AppImageBundler.java:66) at jdk.jpackage/jdk.jpackage.internal.Arguments.generateBundle(Arguments.java:663) ... 3 more

siordache commented 3 years ago

Can you also post the complete output of the jpackageImage task? It should include a dump of the taskData and the jpackage command.

airsquared commented 1 year ago

Closing due to inactivity.