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 <http://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 <http://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 <http://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 <lenbo...@gmail.com
<mailto:lenbo...@gmail.com>>:
I'm experimenting with jpackage from the current EA available
athttps://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
