OK.
May I hope that a fix for this will make its way to the early-access build soon?
(While I can build from source myself, it is much more convenient to use an EA
in our CI cluster.)
/Lennart
> 11 mars 2019 kl. 18:04 skrev Andy Herrick <andy.herr...@oracle.com>:
>
> 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/>
>>> <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
