Filling the Packager gap

[Kevin Rushforth]

No, jlink won't link in a non-modular application. So the steps are:

1) Run jlink to create a Java runtime image, possibly stripped down, and 
include the javafx.* modules you need
2) Run jpackager to package your non-modular application with the above 
Java runtime image.

-- Kevin


On 9/26/2018 3:23 PM, Scott Palmer wrote:
> Does jlink work for non-modular stuff?  The last time I tried it complained to me too.  I guess it gives up because it can’t automatically figure out module dependencies.  The error below shows jlink is what is complaining.
>
> Scott
>
>
>> On Sep 26, 2018, at 3:44 PM, Kevin Rushforth <kevin.rushforth at oracle.com> wrote:
>>
>> 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 at 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 at 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.vos at 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
>>>>