javapackager feedback and questions

Fri Dec 1 00:33:33 UTC 2017

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 <martijnverburg at gmail.com>
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, <victor.drozdov at 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.
>>
>> 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
>>> <https://fpm.readthedocs.io/en/latest/> | GitHub
>>> <https://github.com/jordansissel/fpm>) 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=xxxxx 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 <http://twitter.com/theNeomatrix369>  |  Blog
<http://neomatrix369.wordpress.com/>  |  @adoptopenjdk | Dev communities

Meet-a-Project - MutabilityDetector <https://github.com/MutabilityDetector>
 |  Github <https://github.com/neomatrix369>  | Slideshare
<https://www.slideshare.net/neomatrix369>  | LinkedIn
<http://uk.linkedin.com/pub/mani-sarkar/71/a77/39b>

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!