Looking into the code of Arguments.generateBundle(Map params), I believe it's a
bug to immediately throw an error when a bundler has configuration problems.
Instead, that bundler should be removed from the platformBundlers List.
Quick-and-dirty solution:
diff -r e11f3bf34083
src/jdk.jpackage/share/classes/jdk/jpackage/internal/Arguments.java
--- a/src/jdk.jpackage/share/classes/jdk/jpackage/internal/Arguments.java
Fri Mar 01 08:27:51 2019 -0500
+++ b/src/jdk.jpackage/share/classes/jdk/jpackage/internal/Arguments.java
Mon Mar 11 12:37:43 2019 +0100
@@ -37,6 +37,7 @@
import java.util.HashMap;
import java.util.HashSet;
import java.util.List;
+import java.util.ListIterator;
import java.util.Map;
import java.util.Set;
import java.util.Properties;
@@ -655,7 +656,10 @@
// clean these extra (and unneeded) temp directories.
StandardBundlerParam.BUILD_ROOT.fetchFrom(params);
- for (jdk.jpackage.internal.Bundler bundler : getPlatformBundlers()) {
+ List<jdk.jpackage.internal.Bundler> platformBundlers =
getPlatformBundlers();
+ ListIterator<jdk.jpackage.internal.Bundler> platformBundleIterator =
platformBundlers.listIterator();
+ while (platformBundleIterator.hasNext()) {
+ jdk.jpackage.internal.Bundler bundler =
platformBundleIterator.next();
Map<String, ? super Object> localParams = new HashMap<>(params);
try {
if (bundler.validate(localParams)) {
@@ -677,18 +681,20 @@
} catch (ConfigException e) {
Log.debug(e);
if (e.getAdvice() != null) {
- throw new PackagerException(e,
+ Log.info(new PackagerException(e,
"MSG_BundlerConfigException",
- bundler.getName(), e.getMessage(), e.getAdvice());
+ bundler.getName(), e.getMessage(),
e.getAdvice()).getMessage());
} else {
- throw new PackagerException(e,
+ Log.info(new PackagerException(e,
"MSG_BundlerConfigExceptionNoAdvice",
- bundler.getName(), e.getMessage());
+ bundler.getName(), e.getMessage()).getMessage());
}
+ platformBundleIterator.remove();
} catch (RuntimeException re) {
Log.debug(re);
- throw new PackagerException(re, "MSG_BundlerRuntimeException",
- bundler.getName(), re.toString());
+ Log.info(new PackagerException(re,
"MSG_BundlerRuntimeException",
+ bundler.getName(), re.toString()).getMessage());
+ platformBundleIterator.remove();
} finally {
if (userProvidedBuildRoot) {
Log.verbose(MessageFormat.format(
Best regards,
/Lennart Börjeson
> 11 mars 2019 kl. 09:40 skrev Lennart Börjeson <[email protected]>:
>
> I'm experimenting with jpackage from the current EA available at
> https://jdk.java.net/jpackage/ <https://jdk.java.net/jpackage/>, for the
> moment on Mac only.
>
> I have an existing application which I have previously deployed on multiple
> platforms using the then bundled javafxpackager.
>
> With the current EA (build 17), I find I must specify the --installer-type
> parameter, otherwise I get the following error:
>
> $ /Users/lennartb/Downloads/jdk-13.jdk/Contents/Home/bin/jpackage
> create-installer --overwrite --output
> /Users/lennartb/RaT/git/BMF/GUI/build/jpackage --name bmfgui --app-image
> /Users/lennartb/RaT/git/BMF/GUI/build/jpackage/BMFGraphicalUserInterface.app
> --icon BMF.icns --identifier com.cinnober.bmf.gui.Main --app-version 1.6.10
> --verbose
> jdk.jpackage.internal.PackagerException: Bundler Mac App Store Ready Bundler
> skipped because of a configuration problem: Mac App Store apps must be
> signed, and signing has been disabled by bundler configuration.
> Advice to fix: Either unset 'signBundle' or set 'signBundle' to true.
> at
> jdk.jpackage/jdk.jpackage.internal.Arguments.generateBundle(Arguments.java:726)
> at
> jdk.jpackage/jdk.jpackage.internal.Arguments.processArguments(Arguments.java:642)
> at jdk.jpackage/jdk.jpackage.main.Main.run(Main.java:90)
> at jdk.jpackage/jdk.jpackage.main.Main.main(Main.java:53)
> Caused by: jdk.jpackage.internal.ConfigException: Mac App Store apps must be
> signed, and signing has been disabled by bundler configuration.
> at
> jdk.jpackage/jdk.jpackage.internal.MacAppStoreBundler.validate(MacAppStoreBundler.java:332)
> at
> jdk.jpackage/jdk.jpackage.internal.Arguments.generateBundle(Arguments.java:705)
> ... 3 more
>
> With the previous javafxpackager this wasn't needed. Javafxpackager always
> tried to create all installer types and ignored all errors from any specific
> bundler, e.g. on linux it always tried to create both a Debian package and an
> rpm and just ignored if any of the requisite builder tools was unavailable.
>
> The obvious workaround in my case is to run jpackage twice, once with
> "--installer-type pkg" and once with "--installer-type dmg", but since I'm
> furthered hampered by limitations of my toolchain (gradle +
> badass-jlink-plugin) it would really simplify matters it jpackage could be
> restored to the javafxpackager behaviour when "--installer-type" is
> unspecified, e.g. ignore errors and create whatever installers it can.
>
>
> Best regards,
>
> /Lennart Börjeson
>
>
