jpackage --create-installer problem on Mac when installer-type is unspecified
Andy Herrick
andy.herrick at oracle.com
Tue Mar 12 14:22:44 UTC 2019
Yes expect the next EA by next week.
/Andy
On 3/12/2019 3:40 AM, Lennart Börjeson wrote:
> 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.herrick at oracle.com
>> <mailto:andy.herrick at 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 <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 <lenborje at gmail.com
>>>> <mailto:lenborje at 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
>
More information about the core-libs-dev
mailing list