On Thu, Sep 12, 2019 at 11:28 AM Andy Herrick <andy.herr...@oracle.com> wrote:
> yes - clearly something wrong here - it is supposed to find > MuseIDE-launcher.cfg and create shortcut to MuseIDE-launcher - but it has > come up with jvm.cfg - a completely unrelated file. > > lets see - your input dir is the lib dir of your runtime-image. the app > dir will be populated with everything in the input dir, so it gets jvm.cfg > which is in every runtime's lib dir. > > Not sure why you want to do this, but I think it points out we should not > be satisfied that a file has extension "cfg", we should also look at it and > confirm it looks like a valid jpackage app-image <app>.cfg file, before > deriving the name of the app from the name of the cfg file. > It is entirely possible I *don't* want to do that. I'm admittedly a newbie on this. I'm upgrading an app that used the old packager, via a Gradle plugin, to bundles our app. I'm using a new gradle plugin that is likely less finished, since jpackager is so new :) I've been using https://bugs.openjdk.java.net/browse/JDK-8200758 as a reference, but it is not clear what is and is not yet implemented, thus far. Is there a better source for current docs? What should the input dir point to? Perhaps just the lib folder of my distribution, which contains all the JARs? (I don't need command-line launchers). Thanks again! Chris > /Andy > On 9/12/2019 11:08 AM, Christopher Merrill wrote: > > Thanks Andy. > > Ok, so the image was created in the previous step using: > C:\Apps\OpenJDKs\jdk-14/bin/jpackage.exe --input > D:\Work\MuseProject\ide\closed\install\build\image\lib --main-jar > MuseIDE-launcher-3.1.jar --main-class org.musetest.ide.launcher.Bootstrap > --output D:\Work\MuseProject\ide\closed\install\build\jpackage --name > MuseIDE-launcher --identifier org.musetest.ide.launcher.Bootstrap > --runtime-image D:\Work\MuseProject\ide\closed\install\build\image > > There is only one .cfg file in the .../build/image folder, 'jvm.cfg', > which contains: > -server KNOWN > -client IGNORE > > However, the output folder (../build/jpackage/MuseIDE-launcher/app) of the > second jpackage step which I referenced in the previous message contains a > MuseIDE-launcher.cfg file with: > [Application] > app.name=MuseIDE-launcher > app.version=1.0 > app.runtime=$APPDIR\runtime > app.identifier=org.musetest.ide.launcher.Bootstrap > > app.classpath=$APPDIR\app\MuseIDE-launcher-3.1.jar;$APPDIR\app\dynamic-classloader-0.2.jar;$APPDIR\app\IdeLaunchUpdate-2.3.jar;$APPDIR\app\jrt-fs.jar;$APPDIR\app\update4j-1.2.2.jar > app.mainjar=$APPDIR\app\MuseIDE-launcher-3.1.jar > app.mainclass=org.musetest.ide.launcher.Bootstrap > [JavaOptions] > [ArgOptions] > > I didn't create or supply that file...so I assume jpackage did. > > Could it be the missing windows start menu item be affected by the > location of the main class? In my case, it isn't in the main jar. In fact, > the main jar is empty except for the manifest, which contains only the > manifest version declaration. The main class is located in one of the other > jar files, which are correctly included in the resulting image and > installer. The .cfg correctly includes those JARs on the classpath (and it > all works fine when installed). I don't really see how that should affect > the creation of a shortcut to the .exe, but thought I would mention it. > > TIA! > Chris > > > > On Thu, Sep 12, 2019 at 10:34 AM Andy Herrick <andy.herr...@oracle.com> > wrote: > >> Strange ... >> >> I can't seem to reproduce any scenario where msi installer created by >> jpackage won't install a shortcut, but from the message: >> >> "Multiple launchers found in predefined app-image. jvm will be used as >> primary launcher." >> >> It seems that you are using a predefined app-image and there are >> multiple launchers in the app-image, and the code is choosing "jvm" as >> the primary one (the one a shortcut will be created for). >> >> This may be the wrong launcher. When an installer is built for an >> existing app-image, it doesn't know the name of the app, it looks for >> the config file in <root>/app/ >> >> If there are multiple cfg files (like you built the app-image with >> --add-launcher jvm=jvm-launcher.properties) it is just taking the first >> one. >> >> Is it possible this is what is happening in your case ? >> >> /Andy >> >> On 9/12/2019 9:54 AM, Christopher Merrill wrote: >> > I am using build 14-jpackage+1-35 with WiX 3.11.1.2318 to build an MSI >> > installer. If I am understanding the comments in thread "RFR: >> JDK-8229779: >> > Shortcut creation policy", a start menu entry (and desktop shortcut?) >> > should always be produced with this version of jpackage command line >> > options? The MSI installer I've created does not create a start menu >> entry, >> > even when I include the --win-menu option. Other people seem to have the >> > opposite problem (start menu item when they don't want it), so clearly >> I'm >> > doing something wrong... >> > >> > C:\Apps\OpenJDKs\jdk-14/bin/jpackage --package-type msi --output >> > D:\Work\MuseProject\ide\closed\install\build\jpackage --name >> > MuseIDE-launcher --app-image >> > D:\Work\MuseProject\ide\closed\install\build\jpackage/MuseIDE-launcher >> > --win-per-user-install --win-menu --app-version 3.1 --name >> MuseIDE-Launcher >> > >> > Other than this message, which I assume is a warning, the execution is >> > successful: >> > Multiple launchers found in predefined app-image. jvm will be used as >> > primary launcher. >> > >> > Are there other options that would influence getting a start menu item >> > added by the installer? >> > >> > FWIW, I am using gradle with the org.beryx.runtime plugin to create the >> > image and installer. Are there settings/options/stuff in the image that >> > would affect creation of the start menu item? >> > >> > TIA! >> > Chris >> > >> > > > -- > ¡ɹǝʌo ǝɯ lloɹ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı > > -- ¡ɹǝʌo ǝɯ lloɹ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı
