Re: javapackager feedback and questions

[Mani Sarkar]

Hi Victor,

I have raised an issue on JBS via http://bugreport.java.com/ for this (ID
given to me *9051766*):
> Looks like there is a bug when you specify systemWide=true on the MacOSX
in non-gui mode.

I don't have an account on it, so I might not be able to amend or add new
details to it. If I had to add a word or two to the subject or title of the
issue, how do I do it?

The other doc issues I'll raise as a combined documentation issue, id
*9051768*.

Let me know if you have any other questions or need anything else from me.

Thanks.

Cheers,
Mani
On Wed, 29 Nov 2017 at 23:18  wrote:

> Hi, Mani.
>
> Thanks for providing the feedback!
> We will consider adding more examples and more details in the docs as
> you proposed(there is an arg named jvmOptions but that's not mentioned
> in the table).
> Looks like there is a bug when you specify systemWide=true on the MacOSX
> in non-gui mode. Can you provide more details about that (like full cmd
> line)?
> Actually, if you want you can clone the repo:
> http://hg.openjdk.java.net/openjfx/10-dev/rt/
> (hg clone http://hg.openjdk.java.net/openjfx/10-dev/rt/)
> and help to improve javapackager. Or you can just create Enhancements
> for deploy/packager, as it's not always clear what users expect.
>
> By the way, what kind of apps you distribute using javapackager? Is that
> a UI app or services?
>
> --Victor
>
>
> --

@theNeomatrix369   |  Blog
  |  @adoptopenjdk | Dev communities

Meet-a-Project - MutabilityDetector 
 |  Github   | Slideshare
  | LinkedIn


Come to Devoxx UK 2018: http://www.devoxx.co.uk/

Don't chase success, rather aim for "Excellence", and success will come
chasing after you!

Re: javapackager feedback and questions

[Sverre Moe]

We are using the javapackager through the gradle/maven javafx plugin, to create:
* Executable JAR: When we went from Swing to JavaFX the maven jar
plugin could not create an executable JAR capable to start the JavaFX
Application.
* Native executable bundle: RPM (Linux), EXE (Windows), PKG (Mac)
* Java Web Start bundle

/Sverre

> Date: Thu, 30 Nov 2017 16:16:19 -0800
> From: Kevin Rushforth <kevin.rushfo...@oracle.com>
> To: Michael Hall <mik3h...@gmail.com>
> Cc: "jdk9-...@openjdk.java.net" <jdk9-...@openjdk.java.net>,
> "openjfx-dev@openjdk.java.net" <openjfx-dev@openjdk.java.net>, Mani
>     Sarkar <sadhak...@gmail.com>
> Subject: Re: javapackager feedback and questions
> Message-ID: <5a209f53.6080...@oracle.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Hi Michael,
>
> We realized that the javapackger CLI JEP wasn't quite ready, and was out
> of scope for JDK 10 anyway, so we withdrew it in order to file a new JEP
> later.
>
> Related to this, we are soliciting input as to how people are using the
> javapackager (see Victor's question below).
>
> So we'd love to hear how you and others are using it, and for what kind
> of applications.
>
> -- Kevin
>
>
> Michael Hall wrote:
> >> On Nov 29, 2017, at 5:18 PM, victor.droz...@oracle.com wrote:
> >>
> >> Hi, Mani.
> >>
> >> Thanks for providing the feedback!
> >> We will consider adding more examples and more details in the docs as you 
> >> proposed(there is an arg named jvmOptions but that's not mentioned in the 
> >> table).
> >> Looks like there is a bug when you specify systemWide=true on the MacOSX 
> >> in non-gui mode. Can you provide more details about that (like full cmd 
> >> line)?
> >> Actually, if you want you can clone the repo:
> >> http://hg.openjdk.java.net/openjfx/10-dev/rt/
> >> (hg clone http://hg.openjdk.java.net/openjfx/10-dev/rt/)
> >> and help to improve javapackager. Or you can just create Enhancements for 
> >> deploy/packager, as it's not always clear what users expect.
> >>
> >>
> >
> > Why was JEP 311 [1] Closed/Withdrawn?
> >
> > [1] http://openjdk.java.net/jeps/311
> >
> >

Re: javapackager feedback and questions

[Scott Palmer]

I’m using javapackager to generate native installers for several services and 
GUI applications. I would be using it for some command line tools as well, but 
it doesn’t yet support “console” applications on Windows. I.e. you can’t make 
javapackager with javapackager. I’ve filed an issue for that already (it was 
closed as won’t fix, but thankfully it was reopened)

Javapackager is one of the most useful tools in the JDK, but it is mostly 
undocumented and has many usability issues.
IMO, it tried to do way too much. The only thing it ever needed to do was the 
-deploy option.

I run javapackager two ways, always from Gradle scripts, either via the javaFX 
Gradle plugin, or as an Exec task.

The ability to have secondary launchers is great.

The customization options for installers needs some work. I’ve filed several 
issues (and I could file more). E.g. background images for macOS .dmg must be 
different from background images used in macOS .pkg as they are serving 
entirely different purposes. Including custom resources in subdirectories is 
difficult and/or broken depending on the version of javapackager used (v9 is 
broken).
On Windows .msi component rules are not followed making upgrades problematic. 
Install folders should be customizable by supplying custom wix files, etc.

On Linux services should be handled with systemd or sysctl. (I can’t remember 
which is preferred at the moment, but I know it didn’t use what I needed.)

I really like that we have javapackager and feel it is a very important 
addition to the JDK.  

I too would love if it could build for multiple platforms from a single 
platform, but I honestly don’t see that happening. It isn’t worth the trouble 
or effort - things like making a HFS+ .dmg for macOS from Windows isn’t 
realistic. We do NOT want some custom non-native installer (Though a .zip of an 
app bundle might work.)  You would also need the native bits of the JRE for 
each platform anyway. It would be possible to have those files available on any 
platform, but the tools to build .deb, .rpm, .dmg, .msi, etc. are just never 
going to be available everywhere.

Scott

> On Nov 30, 2017, at 7:16 PM, Kevin Rushforth  
> wrote:
> 
> Hi Michael,
> 
> We realized that the javapackger CLI JEP wasn't quite ready, and was out of 
> scope for JDK 10 anyway, so we withdrew it in order to file a new JEP later.
> 
> Related to this, we are soliciting input as to how people are using the 
> javapackager (see Victor's question below).
> 
> So we'd love to hear how you and others are using it, and for what kind of 
> applications.
> 
> -- Kevin
> 
> 
> Michael Hall wrote:
>>> On Nov 29, 2017, at 5:18 PM, victor.droz...@oracle.com wrote:
>>> 
>>> Hi, Mani.
>>> 
>>> Thanks for providing the feedback!
>>> We will consider adding more examples and more details in the docs as you 
>>> proposed(there is an arg named jvmOptions but that's not mentioned in the 
>>> table).
>>> Looks like there is a bug when you specify systemWide=true on the MacOSX in 
>>> non-gui mode. Can you provide more details about that (like full cmd line)?
>>> Actually, if you want you can clone the repo:
>>> http://hg.openjdk.java.net/openjfx/10-dev/rt/
>>> (hg clone http://hg.openjdk.java.net/openjfx/10-dev/rt/)
>>> and help to improve javapackager. Or you can just create Enhancements for 
>>> deploy/packager, as it's not always clear what users expect.
>>> 
>>>
>> 
>> Why was JEP 311 [1] Closed/Withdrawn?
>> 
>> [1] http://openjdk.java.net/jeps/311
>> 
>>  

Re: javapackager feedback and questions

[Mani Sarkar]

Hi Victor,

To answer your query about how javapackager can be made better, packr (
https://github.com/libgdx/packr) and FPM (
https://github.com/jordansissel/fpm) are two great examples in this space.
If we can pool together some of the features from both, it would certainly
draw attention of  developers building installers and distributable
packages. javapackager does already have many of them already. Packr does
allow compressing jre packed into the app although jlink already helps in
this area. Another example would be to be able to --dry-run your
executions, bundle respective apps as a service (systemd, etc...), see
usage of FPM at https://github.com/jordansissel/fpm/wiki#usage.

Your queries about how people use it or like to use it, one thing FPM and
packr do very well, is to allow creation of packages/installer on a single
platform, their cross-platform functionality is a boon, although building
on native environments have their own merits. Just now one would need to
run javapackager in the specific environments to get a working
installer/package created for that environment. Many would like to run
Jenkins (Linux env) and build all three types of packages/installers on one
box rather than spin off the individual slave variants of different
platforms (Linux, MacOSX and Windows.

I can help draw some enhancement points off this list and share it with you
to avoid noise here, and you can choose to bring them to this list - the
ones you would make part of the packager.

Others might differ in the above and want something else.

I hope this helps.

Cheers,
Mani

On Thu, 30 Nov 2017 at 18:57 Martijn Verburg 
wrote:

> Hi Victor,
>
> I can answer the last Q.  It's for two products, one is Censum our GC Log
> analyser (Java swing desktop app, yes they still exist! ;p) and the second
> is a stand alone Java 'daemon' for our APM SaaS tool (illuminate).
>
> jlink and javapackager is a powerful combination for us, so thanks for
> these tools!
>
> Cheers,
> Martijn
>
> On 29 November 2017 at 23:18,  wrote:
>
>> Hi, Mani.
>>
>> Thanks for providing the feedback!
>> We will consider adding more examples and more details in the docs as you
>> proposed(there is an arg named jvmOptions but that's not mentioned in the
>> table).
>> Looks like there is a bug when you specify systemWide=true on the MacOSX
>> in non-gui mode. Can you provide more details about that (like full cmd
>> line)?
>> Actually, if you want you can clone the repo:
>> http://hg.openjdk.java.net/openjfx/10-dev/rt/
>> (hg clone http://hg.openjdk.java.net/openjfx/10-dev/rt/)
>> and help to improve javapackager. Or you can just create Enhancements for
>> deploy/packager, as it's not always clear what users expect.
>>
>> By the way, what kind of apps you distribute using javapackager? Is that
>> a UI app or services?
>>
>> --Victor
>>
>>
>>
>> On 11/29/17 3:48 AM, Mani Sarkar wrote:
>>
>>> Hi all,
>>>
>>> First I hope I'm writing to the correct mailing list, if not please
>>> suggest
>>> where to write instead. Also if it is worth writing back as separate
>>> messages per issue or item, please do let me know.
>>>
>>> Some of my observations and feedback when using *javapackager*:
>>>
>>> *Positives*
>>> - .dmg and .msi packaging work very well out of the box, easy to put
>>> together configuration settings
>>> - .rpm packages build very quickly
>>> - a number of features from FPM (docs
>>>  | GitHub
>>> ) available but some more for the
>>> individual types of packages would certainly help (for e.g. exposing some
>>> more of the CLI flags for DEB and RPM packaging)
>>>
>>> *Improvements*
>>> - [doc and example required]: Additional documentation and examples
>>> around
>>> how to add a license when building a package would be helpful. After a
>>> bit
>>> of searching on google and experimenting with couple of combinations of
>>> CLI
>>> options I was able to figure it out.
>>> - [doc correction]: jvmUserArg is referred to in the documentation with
>>> examples, while in the usage documentation jvmOptions is used
>>> (discrepancy
>>> between the names of flags), see
>>>
>>> https://docs.oracle.com/javase/8/docs/technotes/tools/unix/javapackager.html
>>>   and
>>>
>>> https://docs.oracle.com/javase/9/deploy/self-contained-application-packaging.htm#JSDPG585
>>> - [doc correction]: same goes for mac.signing-key-user-name while there
>>> is
>>> no mention of it in the javapackager usage documentation, it takes the
>>> full
>>> name of the user i.e. *Jane Doe*
>>> *- *[doc and example required]: just adding
>>> mac.signing-key-developer-id-app=x isn't enough, needs the other
>>> code-sign related flags as well, possibly key should be in the Mac
>>> KeyStore
>>> when building it (check if id provided is the correct one, additional
>>> examples would definitely help to reduce or eliminate experimentation and
>>> assumptions)
>>> 

Re: javapackager feedback and questions

[Michael Hall]

> On Nov 30, 2017, at 6:16 PM, Kevin Rushforth  
> wrote:
> 
> Hi Michael,
> 
> We realized that the javapackger CLI JEP wasn't quite ready, and was out of 
> scope for JDK 10 anyway, so we withdrew it in order to file a new JEP later.
> 
> Related to this, we are soliciting input as to how people are using the 
> javapackager (see Victor's question below).
> 
> So we'd love to hear how you and others are using it, and for what kind of 
> applications.
> 
> — Kevin

I was sort of waiting to see what came out of the JEP. 
It had some issues on OS X the last time I tried it. I might have used it for a 
starter application that I’ve been manually updating since. 
Now I use jlink, copy in the results… That sort of thing. 
I may look at it some more as-is if it doesn’t have a significant update 
currently in the works.

Thanks.

Re: javapackager feedback and questions

[Kevin Rushforth]

Hi Michael,

We realized that the javapackger CLI JEP wasn't quite ready, and was out 
of scope for JDK 10 anyway, so we withdrew it in order to file a new JEP 
later.


Related to this, we are soliciting input as to how people are using the 
javapackager (see Victor's question below).


So we'd love to hear how you and others are using it, and for what kind 
of applications.


-- Kevin


Michael Hall wrote:

On Nov 29, 2017, at 5:18 PM, victor.droz...@oracle.com wrote:

Hi, Mani.

Thanks for providing the feedback!
We will consider adding more examples and more details in the docs as you 
proposed(there is an arg named jvmOptions but that's not mentioned in the 
table).
Looks like there is a bug when you specify systemWide=true on the MacOSX in 
non-gui mode. Can you provide more details about that (like full cmd line)?
Actually, if you want you can clone the repo:
http://hg.openjdk.java.net/openjfx/10-dev/rt/
(hg clone http://hg.openjdk.java.net/openjfx/10-dev/rt/)
and help to improve javapackager. Or you can just create Enhancements for 
deploy/packager, as it's not always clear what users expect.




Why was JEP 311 [1] Closed/Withdrawn?

[1] http://openjdk.java.net/jeps/311

  

Re: javapackager feedback and questions

[Martijn Verburg]

Hi Victor,

I can answer the last Q.  It's for two products, one is Censum our GC Log
analyser (Java swing desktop app, yes they still exist! ;p) and the second
is a stand alone Java 'daemon' for our APM SaaS tool (illuminate).

jlink and javapackager is a powerful combination for us, so thanks for
these tools!

Cheers,
Martijn

On 29 November 2017 at 23:18,  wrote:

> Hi, Mani.
>
> Thanks for providing the feedback!
> We will consider adding more examples and more details in the docs as you
> proposed(there is an arg named jvmOptions but that's not mentioned in the
> table).
> Looks like there is a bug when you specify systemWide=true on the MacOSX
> in non-gui mode. Can you provide more details about that (like full cmd
> line)?
> Actually, if you want you can clone the repo:
> http://hg.openjdk.java.net/openjfx/10-dev/rt/
> (hg clone http://hg.openjdk.java.net/openjfx/10-dev/rt/)
> and help to improve javapackager. Or you can just create Enhancements for
> deploy/packager, as it's not always clear what users expect.
>
> By the way, what kind of apps you distribute using javapackager? Is that a
> UI app or services?
>
> --Victor
>
>
>
> On 11/29/17 3:48 AM, Mani Sarkar wrote:
>
>> Hi all,
>>
>> First I hope I'm writing to the correct mailing list, if not please
>> suggest
>> where to write instead. Also if it is worth writing back as separate
>> messages per issue or item, please do let me know.
>>
>> Some of my observations and feedback when using *javapackager*:
>>
>> *Positives*
>> - .dmg and .msi packaging work very well out of the box, easy to put
>> together configuration settings
>> - .rpm packages build very quickly
>> - a number of features from FPM (docs
>>  | GitHub
>> ) available but some more for the
>> individual types of packages would certainly help (for e.g. exposing some
>> more of the CLI flags for DEB and RPM packaging)
>>
>> *Improvements*
>> - [doc and example required]: Additional documentation and examples around
>> how to add a license when building a package would be helpful. After a bit
>> of searching on google and experimenting with couple of combinations of
>> CLI
>> options I was able to figure it out.
>> - [doc correction]: jvmUserArg is referred to in the documentation with
>> examples, while in the usage documentation jvmOptions is used (discrepancy
>> between the names of flags), see
>> https://docs.oracle.com/javase/8/docs/technotes/tools/unix/
>> javapackager.html
>>   and
>> https://docs.oracle.com/javase/9/deploy/self-contained-
>> application-packaging.htm#JSDPG585
>> - [doc correction]: same goes for mac.signing-key-user-name while there is
>> no mention of it in the javapackager usage documentation, it takes the
>> full
>> name of the user i.e. *Jane Doe*
>> *- *[doc and example required]: just adding
>> mac.signing-key-developer-id-app=x isn't enough, needs the other
>> code-sign related flags as well, possibly key should be in the Mac
>> KeyStore
>> when building it (check if id provided is the correct one, additional
>> examples would definitely help to reduce or eliminate experimentation and
>> assumptions)
>> - [potential bug]: Using *-B*systemWide=true flag causes error -10810 when
>> building on the MacOSX in non-gui mode, can be overridden by using the
>> -Bmac.dmg.simple=true but we loose the backdrop and automatic shortcut
>> creation, etc... Swappin gthe order to: -Bmac.dmg.simple=true and *-B*
>> systemWide=true does not help, still ends up building a .dmg package with
>> just the app in it (no icon, no background)
>> - code signing examples for Windows and MacOSX will certainly help quite a
>> bit
>> - [doc and example required] .deb packages take a long time to build, some
>> additional flags that can help. Some findings along the lines on how to
>> speed up dpkg-build:
>>
>> export CCACHE_DIR=/home/$USER/.ccache
>>
>> export CCACHE_HASHDIR=$CCACHE_DIR
>>
>> export DEB_BUILD_OPTIONS="${DEB_BUILD_OPTIONS}
>> --preserve-envvar=CCACHE_DIR
>> --prepend-path=/usr/lib/ccache parallel=jobs"
>>
>> echo "Debian build options: ${DEB_BUILD_OPTIONS}"
>>
>> ---
>>
>> A response with answers for the above will be highly appreciated.
>>
>> Thanks.
>>
>> Cheers,
>> Mani
>>
>
>

Re: javapackager feedback and questions

[Mani Sarkar]

Thanks Victor for you response and invite. I'll get back with details for
your query.

Just for your info, I was referring to javapackager in the context of Java
9 built artifacts.

On Thu, 30 Nov 2017 09:28 Michael Hall,  wrote:

>
> > On Nov 29, 2017, at 5:18 PM, victor.droz...@oracle.com wrote:
> >
> > Hi, Mani.
> >
> > Thanks for providing the feedback!
> > We will consider adding more examples and more details in the docs as
> you proposed(there is an arg named jvmOptions but that's not mentioned in
> the table).
> > Looks like there is a bug when you specify systemWide=true on the MacOSX
> in non-gui mode. Can you provide more details about that (like full cmd
> line)?
> > Actually, if you want you can clone the repo:
> > http://hg.openjdk.java.net/openjfx/10-dev/rt/
> > (hg clone http://hg.openjdk.java.net/openjfx/10-dev/rt/)
> > and help to improve javapackager. Or you can just create Enhancements
> for deploy/packager, as it's not always clear what users expect.
> >
>
> Why was JEP 311 [1] Closed/Withdrawn?
>
> [1] http://openjdk.java.net/jeps/311
>
> --

@theNeomatrix369   |  Blog
  |  @adoptopenjdk | Dev communities

Meet-a-Project - MutabilityDetector 
 |  Github   | Slideshare
  | LinkedIn


Come to Devoxx UK 2018: http://www.devoxx.co.uk/

Don't chase success, rather aim for "Excellence", and success will come
chasing after you!

Re: javapackager feedback and questions

[Michael Hall]

> On Nov 29, 2017, at 5:18 PM, victor.droz...@oracle.com wrote:
> 
> Hi, Mani.
> 
> Thanks for providing the feedback!
> We will consider adding more examples and more details in the docs as you 
> proposed(there is an arg named jvmOptions but that's not mentioned in the 
> table).
> Looks like there is a bug when you specify systemWide=true on the MacOSX in 
> non-gui mode. Can you provide more details about that (like full cmd line)?
> Actually, if you want you can clone the repo:
> http://hg.openjdk.java.net/openjfx/10-dev/rt/
> (hg clone http://hg.openjdk.java.net/openjfx/10-dev/rt/)
> and help to improve javapackager. Or you can just create Enhancements for 
> deploy/packager, as it's not always clear what users expect.
> 

Why was JEP 311 [1] Closed/Withdrawn?

[1] http://openjdk.java.net/jeps/311

Re: javapackager feedback and questions

[Michael Paus]

Hi,
I am wondering why you can say that ".dmg and .msi packaging work very well"
because there is this still open bug 
https://bugs.openjdk.java.net/browse/JDK-8179033
which keeps me from building DMG files on Java 9. Are you still using 
Java 8?

Michael

Am 29.11.17 um 12:48 schrieb Mani Sarkar:

Hi all,

First I hope I'm writing to the correct mailing list, if not please suggest
where to write instead. Also if it is worth writing back as separate
messages per issue or item, please do let me know.

Some of my observations and feedback when using *javapackager*:

*Positives*
- .dmg and .msi packaging work very well out of the box, easy to put
together configuration settings
- .rpm packages build very quickly
- a number of features from FPM (docs
 | GitHub
) available but some more for the
individual types of packages would certainly help (for e.g. exposing some
more of the CLI flags for DEB and RPM packaging)

*Improvements*
- [doc and example required]: Additional documentation and examples around
how to add a license when building a package would be helpful. After a bit
of searching on google and experimenting with couple of combinations of CLI
options I was able to figure it out.
- [doc correction]: jvmUserArg is referred to in the documentation with
examples, while in the usage documentation jvmOptions is used (discrepancy
between the names of flags), see
https://docs.oracle.com/javase/8/docs/technotes/tools/unix/javapackager.html
  and
https://docs.oracle.com/javase/9/deploy/self-contained-application-packaging.htm#JSDPG585
- [doc correction]: same goes for mac.signing-key-user-name while there is
no mention of it in the javapackager usage documentation, it takes the full
name of the user i.e. *Jane Doe*
*- *[doc and example required]: just adding
mac.signing-key-developer-id-app=x isn't enough, needs the other
code-sign related flags as well, possibly key should be in the Mac KeyStore
when building it (check if id provided is the correct one, additional
examples would definitely help to reduce or eliminate experimentation and
assumptions)
- [potential bug]: Using *-B*systemWide=true flag causes error -10810 when
building on the MacOSX in non-gui mode, can be overridden by using the
-Bmac.dmg.simple=true but we loose the backdrop and automatic shortcut
creation, etc... Swappin gthe order to: -Bmac.dmg.simple=true and *-B*
systemWide=true does not help, still ends up building a .dmg package with
just the app in it (no icon, no background)
- code signing examples for Windows and MacOSX will certainly help quite a
bit
- [doc and example required] .deb packages take a long time to build, some
additional flags that can help. Some findings along the lines on how to
speed up dpkg-build:

export CCACHE_DIR=/home/$USER/.ccache

export CCACHE_HASHDIR=$CCACHE_DIR

export DEB_BUILD_OPTIONS="${DEB_BUILD_OPTIONS} --preserve-envvar=CCACHE_DIR
--prepend-path=/usr/lib/ccache parallel=jobs"

echo "Debian build options: ${DEB_BUILD_OPTIONS}"

---

A response with answers for the above will be highly appreciated.

Thanks.

Cheers,
Mani

Re: javapackager feedback and questions

[victor . drozdov]

Hi, Mani.

Thanks for providing the feedback!
We will consider adding more examples and more details in the docs as 
you proposed(there is an arg named jvmOptions but that's not mentioned 
in the table).
Looks like there is a bug when you specify systemWide=true on the MacOSX 
in non-gui mode. Can you provide more details about that (like full cmd 
line)?

Actually, if you want you can clone the repo:
http://hg.openjdk.java.net/openjfx/10-dev/rt/
(hg clone http://hg.openjdk.java.net/openjfx/10-dev/rt/)
and help to improve javapackager. Or you can just create Enhancements 
for deploy/packager, as it's not always clear what users expect.


By the way, what kind of apps you distribute using javapackager? Is that 
a UI app or services?


--Victor


On 11/29/17 3:48 AM, Mani Sarkar wrote:

Hi all,

First I hope I'm writing to the correct mailing list, if not please suggest
where to write instead. Also if it is worth writing back as separate
messages per issue or item, please do let me know.

Some of my observations and feedback when using *javapackager*:

*Positives*
- .dmg and .msi packaging work very well out of the box, easy to put
together configuration settings
- .rpm packages build very quickly
- a number of features from FPM (docs
 | GitHub
) available but some more for the
individual types of packages would certainly help (for e.g. exposing some
more of the CLI flags for DEB and RPM packaging)

*Improvements*
- [doc and example required]: Additional documentation and examples around
how to add a license when building a package would be helpful. After a bit
of searching on google and experimenting with couple of combinations of CLI
options I was able to figure it out.
- [doc correction]: jvmUserArg is referred to in the documentation with
examples, while in the usage documentation jvmOptions is used (discrepancy
between the names of flags), see
https://docs.oracle.com/javase/8/docs/technotes/tools/unix/javapackager.html
  and
https://docs.oracle.com/javase/9/deploy/self-contained-application-packaging.htm#JSDPG585
- [doc correction]: same goes for mac.signing-key-user-name while there is
no mention of it in the javapackager usage documentation, it takes the full
name of the user i.e. *Jane Doe*
*- *[doc and example required]: just adding
mac.signing-key-developer-id-app=x isn't enough, needs the other
code-sign related flags as well, possibly key should be in the Mac KeyStore
when building it (check if id provided is the correct one, additional
examples would definitely help to reduce or eliminate experimentation and
assumptions)
- [potential bug]: Using *-B*systemWide=true flag causes error -10810 when
building on the MacOSX in non-gui mode, can be overridden by using the
-Bmac.dmg.simple=true but we loose the backdrop and automatic shortcut
creation, etc... Swappin gthe order to: -Bmac.dmg.simple=true and *-B*
systemWide=true does not help, still ends up building a .dmg package with
just the app in it (no icon, no background)
- code signing examples for Windows and MacOSX will certainly help quite a
bit
- [doc and example required] .deb packages take a long time to build, some
additional flags that can help. Some findings along the lines on how to
speed up dpkg-build:

export CCACHE_DIR=/home/$USER/.ccache

export CCACHE_HASHDIR=$CCACHE_DIR

export DEB_BUILD_OPTIONS="${DEB_BUILD_OPTIONS} --preserve-envvar=CCACHE_DIR
--prepend-path=/usr/lib/ccache parallel=jobs"

echo "Debian build options: ${DEB_BUILD_OPTIONS}"

---

A response with answers for the above will be highly appreciated.

Thanks.

Cheers,
Mani

javapackager feedback and questions

[Mani Sarkar]

Hi all,

First I hope I'm writing to the correct mailing list, if not please suggest
where to write instead. Also if it is worth writing back as separate
messages per issue or item, please do let me know.

Some of my observations and feedback when using *javapackager*:

*Positives*
- .dmg and .msi packaging work very well out of the box, easy to put
together configuration settings
- .rpm packages build very quickly
- a number of features from FPM (docs
 | GitHub
) available but some more for the
individual types of packages would certainly help (for e.g. exposing some
more of the CLI flags for DEB and RPM packaging)

*Improvements*
- [doc and example required]: Additional documentation and examples around
how to add a license when building a package would be helpful. After a bit
of searching on google and experimenting with couple of combinations of CLI
options I was able to figure it out.
- [doc correction]: jvmUserArg is referred to in the documentation with
examples, while in the usage documentation jvmOptions is used (discrepancy
between the names of flags), see
https://docs.oracle.com/javase/8/docs/technotes/tools/unix/javapackager.html
 and
https://docs.oracle.com/javase/9/deploy/self-contained-application-packaging.htm#JSDPG585
- [doc correction]: same goes for mac.signing-key-user-name while there is
no mention of it in the javapackager usage documentation, it takes the full
name of the user i.e. *Jane Doe*
*- *[doc and example required]: just adding
mac.signing-key-developer-id-app=x isn't enough, needs the other
code-sign related flags as well, possibly key should be in the Mac KeyStore
when building it (check if id provided is the correct one, additional
examples would definitely help to reduce or eliminate experimentation and
assumptions)
- [potential bug]: Using *-B*systemWide=true flag causes error -10810 when
building on the MacOSX in non-gui mode, can be overridden by using the
-Bmac.dmg.simple=true but we loose the backdrop and automatic shortcut
creation, etc... Swappin gthe order to: -Bmac.dmg.simple=true and *-B*
systemWide=true does not help, still ends up building a .dmg package with
just the app in it (no icon, no background)
- code signing examples for Windows and MacOSX will certainly help quite a
bit
- [doc and example required] .deb packages take a long time to build, some
additional flags that can help. Some findings along the lines on how to
speed up dpkg-build:

export CCACHE_DIR=/home/$USER/.ccache

export CCACHE_HASHDIR=$CCACHE_DIR

export DEB_BUILD_OPTIONS="${DEB_BUILD_OPTIONS} --preserve-envvar=CCACHE_DIR
--prepend-path=/usr/lib/ccache parallel=jobs"

echo "Debian build options: ${DEB_BUILD_OPTIONS}"

---

A response with answers for the above will be highly appreciated.

Thanks.

Cheers,
Mani
-- 

@theNeomatrix369   |  Blog
  |  @adoptopenjdk | Dev communities

Meet-a-Project - MutabilityDetector 
 |  Github   | Slideshare
  | LinkedIn


Come to Devoxx UK 2018: http://www.devoxx.co.uk/

Don't chase success, rather aim for "Excellence", and success will come
chasing after you!