From kevin.rushforth at oracle.com Fri Dec 1 00:16:19 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 30 Nov 2017 16:16:19 -0800 Subject: javapackager feedback and questions In-Reply-To: References: <4729a893-3faa-c3ee-9669-ff932a0912de@oracle.com> Message-ID: <5A209F53.6080707@oracle.com> 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.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. >> >> > > Why was JEP 311 [1] Closed/Withdrawn? > > [1] http://openjdk.java.net/jeps/311 > > From sadhak001 at gmail.com Fri Dec 1 00:33:33 2017 From: sadhak001 at gmail.com (Mani Sarkar) Date: Fri, 01 Dec 2017 00:33:33 +0000 Subject: javapackager feedback and questions In-Reply-To: References: <4729a893-3faa-c3ee-9669-ff932a0912de@oracle.com> Message-ID: 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=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 | 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! From swpalmer at gmail.com Fri Dec 1 03:23:21 2017 From: swpalmer at gmail.com (Scott Palmer) Date: Thu, 30 Nov 2017 22:23:21 -0500 Subject: javapackager feedback and questions In-Reply-To: <5A209F53.6080707@oracle.com> References: <4729a893-3faa-c3ee-9669-ff932a0912de@oracle.com> <5A209F53.6080707@oracle.com> Message-ID: <2054E56A-27E2-40FD-91D7-A3FEE73F0B08@gmail.com> 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.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. >>> >>> >> >> Why was JEP 311 [1] Closed/Withdrawn? >> >> [1] http://openjdk.java.net/jeps/311 >> >> From sadhak001 at gmail.com Mon Dec 4 11:39:39 2017 From: sadhak001 at gmail.com (Mani Sarkar) Date: Mon, 04 Dec 2017 11:39:39 +0000 Subject: javapackager feedback and questions In-Reply-To: <4729a893-3faa-c3ee-9669-ff932a0912de@oracle.com> References: <4729a893-3faa-c3ee-9669-ff932a0912de@oracle.com> Message-ID: 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! From sadhak001 at gmail.com Wed Dec 6 15:58:28 2017 From: sadhak001 at gmail.com (Mani Sarkar) Date: Wed, 06 Dec 2017 15:58:28 +0000 Subject: javapackager: MacOSX: question about adding a file to the DMG outside of the app bundler Message-ID: Hi, Has anyone worked out how to add a file like a README.txt into the DMG volume such that its not bundled into the app bundler (.app file) but placed outside it so that it is visible when the DMG volume is mounted for installation? It sounds like a simple action but the usage or docs don't point to it directly - from the options so far, it seems it might not be possible. How else can we present this to the end-user? Any thoughts on this? 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! From randomdsdevel at gmail.com Fri Dec 8 02:30:12 2017 From: randomdsdevel at gmail.com (Bryce Glover) Date: Thu, 7 Dec 2017 21:30:12 -0500 Subject: Asking a Small Favor Message-ID: <90FD5865-7ABE-4067-9702-9A6761891CEE@gmail.com> To Whom It May Concern, Could somebody please close JDK-8188077 for me? It?s no longer relevant, as the relevant update server URIs actually had their lack of content fixed just prior to the public release of JRE/JDK v9.0.1, build 11. I?d have said so and done it myself, but I don?t yet have the proper ?Author? role privileges/permissions required to get a JIRA account per the OpenJDK bylaws (took me a little while to figure that out, but I managed it eventually; man, that documentation is?a tad scattered into some tiny nooks and crannies, if I may say so.) Thanks in advance and regards, Bryce Glover RandomDSdevel at gmail.com From david.holmes at oracle.com Fri Dec 8 02:39:48 2017 From: david.holmes at oracle.com (David Holmes) Date: Fri, 8 Dec 2017 12:39:48 +1000 Subject: Asking a Small Favor In-Reply-To: <90FD5865-7ABE-4067-9702-9A6761891CEE@gmail.com> References: <90FD5865-7ABE-4067-9702-9A6761891CEE@gmail.com> Message-ID: <4b5dcfca-4cd2-cb5a-1019-e106dcd1a87c@oracle.com> It's already closed Bryce, but I added your comments. Cheers, David On 8/12/2017 12:30 PM, Bryce Glover wrote: > To Whom It May Concern, > > Could somebody please close JDK-8188077 for me? It?s no longer relevant, as the relevant update server URIs actually had their lack of content fixed just prior to the public release of JRE/JDK v9.0.1, build 11. I?d have said so and done it myself, but I don?t yet have the proper ?Author? role privileges/permissions required to get a JIRA account per the OpenJDK bylaws (took me a little while to figure that out, but I managed it eventually; man, that documentation is?a tad scattered into some tiny nooks and crannies, if I may say so.) > > Thanks in advance and regards, > Bryce Glover > RandomDSdevel at gmail.com > From randomdsdevel at gmail.com Fri Dec 8 04:16:13 2017 From: randomdsdevel at gmail.com (Bryce Glover) Date: Thu, 7 Dec 2017 23:16:13 -0500 Subject: Asking a Small Favor In-Reply-To: <4b5dcfca-4cd2-cb5a-1019-e106dcd1a87c@oracle.com> References: <90FD5865-7ABE-4067-9702-9A6761891CEE@gmail.com> <4b5dcfca-4cd2-cb5a-1019-e106dcd1a87c@oracle.com> Message-ID: > On Dec 7, 2017, at 9:39 PM, David Holmes wrote: > > It's already closed Bryce, but I added your comments. > > Cheers, > David Huh, hadn?t noticed, though perhaps I was just overlooking the relevant page UI. In any case, thanks a lot for the help! Regards, Bryce Glover RandomDSdevel at gmail.com From mik3hall at gmail.com Fri Dec 1 00:20:59 2017 From: mik3hall at gmail.com (Michael Hall) Date: Thu, 30 Nov 2017 18:20:59 -0600 Subject: javapackager feedback and questions In-Reply-To: <5A209F53.6080707@oracle.com> References: <4729a893-3faa-c3ee-9669-ff932a0912de@oracle.com> <5A209F53.6080707@oracle.com> Message-ID: > 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. From cpennello at opentable.com Mon Dec 18 22:23:40 2017 From: cpennello at opentable.com (Chris Pennello) Date: Mon, 18 Dec 2017 22:23:40 +0000 Subject: jdk 9 early-access builds for alpine linux Message-ID: <04A5DA1D-7CFD-4CE5-A8B3-2FE49C6413E4@opentable.com> Hello, We're interested in using the JDK 9 builds for Alpine Linux. We see that the currently-available builds are early-access, and are a little behind the GA release (e.g., they don't include support for the --add-opens option). http://jdk.java.net/9/ea We were wondering what the roadmap is for the Alpine Linux builds. Is there a plan to move from early-access to GA builds? Will GA builds be regularly supported for musl C, the same as are supported for glibc? We could, of course, build our own, but it would be advantageous if we could use the same builds that "everyone else" is using. Chris