jpackager should work for non-modular applications as well as modular ones. We've tested it for simple applications with or without FX. In the latter case, the testing I've done has been done by first using jlink to create a Java runtime with the needed JDK modules + the openjfx11 modules (using the jomds).

Andy might have additional comments.

-- Kevin


On 9/26/2018 11:50 AM, Sverre Moe wrote:
I have tried this jpackager a bit. It is working fine packaging a Java
modular project.
However it fails to package a none modular project. I modified my project
and removed the modularization and tried again to see if it would work to
package our legacy Java 8 project (though now built with JDK 11 and with
dependencies on openjfx 11).

I was under the impression that the jpackager should also work to package
non-modular projects.

The Gradle distribution task produces an tar archive with all the
dependencies and my own JAR, which I am using as input to the jpackager.

This produces the RPM for the modular project:
sverre@mintaka:~/workspace/movies/build/distributions/movies-1.0-SNAPSHOT/lib>
~/Downloads/jdk.packager-linux/jpackager create-installer --output outputDir
--verbose --echo-mode --module-path . --module
no.smeaworks.movies/no.smeaworks.movies.MoviesApplication

Using the jpackager to package non modular project:
sverre@mintaka:~/workspace/movies-java11/build/distributions/movies-1.0-SNAPSHOT>
~/Downloads/jdk.packager-linux/jpackager create-installer --input lib --output
outputDir --verbose --echo-mode --class
no.smeaworks.movies.MoviesApplication --main-jar movies-1.0-SNAPSHOT.jar


ECHO-MODE: Running [rpmbuild, --version]

"Adding modules: [] to runtime image."

ECHO-MODE: Running jlink [
--output =
/tmp/jdk.packager8937818818558013564/images/linux-rpm.image/movies/runtime
--module-path = [/usr/lib64/jvm/java-11-openjdk-11/jmods]
--add-modules = []
--limit-modules = []
--exclude-files = .*\.diz
--strip-native-commands = false
]
/tmp/jdk.packager8937818818558013564/images/linux-rpm.image/movies/runtime
Exception: jdk.tools.jlink.plugin.PluginException: java.io.IOException:
jdk.tools.jlink.plugin.PluginException: ModuleTarget attribute is missing
for java.base module
Config files are saved to /tmp/jdk.packager8937818818558013564/linux. Use
them to customize package.
Exception in thread "main" jdk.packager.internal.PackagerException: Error:
Bundler "RPM Bundle" (rpm) failed to produce a bundle.
        at
jdk.packager/jdk.packager.internal.Arguments.generateBundle(Arguments.java:642)

        at
jdk.packager/jdk.packager.internal.Arguments.processArguments(Arguments.java:582)

        at jdk.packager/jdk.packager.Main.run(Main.java:71)
        at jdk.packager/jdk.packager.Main.main(Main.java:47)


Is my presumption wrong that it should package also non modular projects,
or am I missing some runtime flags to jpackager?

Johan, you mentioned that Gluon is using this to package SceneBuilder 11. I
reckon that Gluon has yet to modularize SceneBuilder? Can you provide some
insight how you use jpackage to build the project? I could not find
anything on it in the Gluon SceneBuilder GitHub repository.

/Sverre

Den ons. 19. sep. 2018 kl. 10:56 skrev Johan Vos <johan....@gluonhq.com>:

Hi,

As promised, we looked into an interim solution for the packager-gap. Work
for the new Java Packager (12?) is being done in the OpenJDK sandbox repo.
We backported the required changes to an OpenJDK 11 mirror:
https://github.com/johanvos/openjdk-mobile11/tree/packager

With this, we created modified OpenJDK 11 builds that contain the packager
(wrapper/exe + module including native library). They can be downloaded and
tested/used at

http://download2.gluonhq.com/jpackager/11/jdk.packager-linux.zip
http://download2.gluonhq.com/jpackager/11/jdk.packager-osx.zip
http://download2.gluonhq.com/jpackager/11/jdk.packager-windows.zip

For Windows, you have to unzip the bundle in the same directory as the JDK,
as the packager wrapper expect to find the java binary at the same level.

Note that these are not products. We use them internally to create
installers (e.g. we're using them for Scene Builder 11 and that works
fine), and they do what we expect them to do, but there are no guarantees
of course so at least for now I recommend using them in development only
(or even better, look at the changes and contribute to
https://bugs.openjdk.java.net/browse/JDK-8200758 or to this backport)

- Johan


Reply via email to