Although we plan to remove the mac-app-store intaller type for the first
release (which will fix this instance the problem for now) I agree this
is not right for an exception in one install type to prevent the other
types (if there are any) from running.
I think instead though we should try to run them all, then log what
succeeded and then throw the exception if any failed.
/Andy
On 3/11/2019 7:55 AM, Lennart Börjeson wrote:
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 <lenbo...@gmail.com>:
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
