Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

+1 (Approved). I think we are now just waiting on the CSR to be approved : https://bugs.openjdk.java.net/browse/JDK-8213087 -phil. On 12/3/19, 12:31 PM, Kevin Rushforth wrote: Updated version (with the one change mentioned in reply to Phil) looks good. +1 -- Kevin On 12/3/2019 11:35 AM,

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

Updated version (with the one change mentioned in reply to Phil) looks good. +1 -- Kevin On 12/3/2019 11:35 AM, Andy Herrick wrote: Please review the revised cumulative jpackage webrev at [3] /Andy [3] http://cr.openjdk.java.net/~herrick/8212780/webrev.EA-11D/ On 11/18/2019 12:01 PM,

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

On 12/2/2019 2:07 PM, Phil Race wrote: This makes it very difficult to do more than a cursory re-review. There is one thing I just spotted. I believe these two scripts http://cr.openjdk.java.net/~herrick/8212780/webrev.EA-11/test/jdk/tools/jpackage/test_jpackage.sh.html

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

Please review the revised cumulative jpackage webrev at [3] /Andy [3] http://cr.openjdk.java.net/~herrick/8212780/webrev.EA-11D/ On 11/18/2019 12:01 PM, Andy Herrick wrote: On 11/13/2019 7:23 PM, Andy Herrick wrote: Please review  changes for [1] which is the implementation bug for

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

This makes it very difficult to do more than a cursory re-review. There is one thing I just spotted. I believe these two scripts http://cr.openjdk.java.net/~herrick/8212780/webrev.EA-11/test/jdk/tools/jpackage/test_jpackage.sh.html

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

yes - The attempted incremental patch is not much use.  The source files were moved several times, and despite using "hg addremove -s 60", many of the files show as a remove and a new file. /Andy On 11/26/2019 9:01 PM, Philip Race wrote: > I believe otherwise it is an accurate incremental

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

> I believe otherwise it is an accurate incremental webrev of the jpackage changes since EA-5. It is also not very incremental. * *src/jdk.incubator.jpackage/share/classes/jdk/incubator/jpackage/main/Main.java is definitely not "new" ... -phil. On 11/26/19, 2:17 PM, Andy Herrick wrote: yes,

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

yes,  this incremental webrev contains the JNLPConverter code, which it should not. I believe otherwise it is an accurate incremental webrev of the jpackage changes since EA-5. /Andy On 11/26/2019 4:53 PM, Phil Race wrote: Andy, I am puzzled by what I see here > The webrev at [3] shows

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

Andy, I am puzzled by what I see here > The webrev at [3] shows the changes since EA-06 (Build 13-jpackage+1-49 ) up to the current point. > [3] http://cr.openjdk.java.net/~herrick/8212780/webrev.06-10/ This includes the JNLPConverter which isn't what I expected to see and (correctly) isn't

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

This all looks good. +1 -- Kevin On 11/26/2019 12:56 PM, Erik Joelsson wrote: (adding build-dev) Build changes look good. /Erik On 2019-11-20 09:37, Andy Herrick wrote: I posted new composite webrev [7], and git patch [8] after pushing fix for JDK-8234402 [6]. [7]

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

(adding build-dev) Build changes look good. /Erik On 2019-11-20 09:37, Andy Herrick wrote: I posted new composite webrev [7], and git patch [8] after pushing fix for JDK-8234402 [6]. [7] http://cr.openjdk.java.net/~herrick/8212780/webrev.EA-11/ [8]

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

I posted new composite webrev [7], and git patch [8] after pushing fix for JDK-8234402 [6]. [7] http://cr.openjdk.java.net/~herrick/8212780/webrev.EA-11/ [8] http://cr.openjdk.java.net/~herrick/8212780/JDK-EA-11.git.patch /Andy On 11/19/2019 3:13 PM, Kevin Rushforth wrote: I took the "git

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

I took the "git diff" patch [5] that you uploaded yesterday, applied it, and verified that it is the same as what is in the JDK-8200758-branch branch of the sandbox. It builds and runs fine for me. I ran jcheck and it found the following three files with whitespace errors that will need to be

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

On 11/13/2019 7:23 PM, Andy Herrick wrote: Please review  changes for [1] which is the implementation bug for JEP-343. The webrev at [2] is the total cumulative webrev of changes for the jpackage tool, currently in the JDK-8200758-branch branch of the open sandbox repository. The webrev

RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

Please review  changes for [1] which is the implementation bug for JEP-343. The webrev at [2] is the total cumulative webrev of changes for the jpackage tool, currently in the JDK-8200758-branch branch of the open sandbox repository. The webrev at [3] shows the changes since EA-06 (Build

RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

Please review  changes for [1] which is the implementation bug for JEP-343. The webrev at [2] is the total cumulative webrev of changes for the jpackage tool, currently in the JDK-8200758-branch branch of the open sandbox repository. The webrev at [3] shows the changes since EA-06 (Build

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

On 5/10/2019 3:39 PM, Roger Riggs wrote: Hi Andy, Thanks for logging the issues. CLIHelp:  - 58, 65, 72, 80: Indentation of pLaunchOptions does not line up. I don't see what you mean here.  Looks lined up to me The lines with pLaunchOptions have tabs instead of spaces. jcheck has some

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

Hi Andy, Thanks for logging the issues. CLIHelp:  - 58, 65, 72, 80: Indentation of pLaunchOptions does not line up. I don't see what you mean here.  Looks lined up to me The lines with pLaunchOptions have tabs instead of spaces. jcheck has some complaints about tabs and trailing spaces.

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

On 5/7/2019 4:39 PM, Roger Riggs wrote: Hi, Additional comments/observations on the jpackage webrev. Cleanup opportunities for more maintainable code. When using the ToolProvider API in an application that has a security manager, what permissions must be available?  Properties, files,

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

Hi, Additional comments/observations on the jpackage webrev. Cleanup opportunities for more maintainable code. When using the ToolProvider API in an application that has a security manager, what permissions must be available?  Properties, files, ...? Main:  91: "processArguments" seems

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

looks good. /Andy On 5/3/2019 2:08 PM, Kevin Rushforth wrote: Here is the webrev to document the threading limitation: https://bugs.openjdk.java.net/browse/JDK-8223321 http://cr.openjdk.java.net/~kcr/8223321/webrev.00/ Once reviewed, Andy can include this in the next version of the webrev

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

OK, thanks. -- Kevin On 5/3/2019 11:31 AM, Roger Riggs wrote: Hi Kevin, I'm fine with the disclaimer; undefined behavior is fine. Thanks, Roger p.s. synchronizing the run method would prevent filing of issues when someone does it anyway, keeping the noise to a minimum. On 05/03/2019 02:08

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

Looks good to me. We can live with this limitation for a little while, since there aren't exactly thousands of users who will need to run this concurrently. And concurrent use of the command line tool - ie using separate VMs works fine - per Kevin. But we do need to get to it. -phil. On

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

Hi Kevin, I'm fine with the disclaimer; undefined behavior is fine. Thanks, Roger p.s. synchronizing the run method would prevent filing of issues when someone does it anyway, keeping the noise to a minimum. On 05/03/2019 02:08 PM, Kevin Rushforth wrote: Here is the webrev to document the

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

Here is the webrev to document the threading limitation: https://bugs.openjdk.java.net/browse/JDK-8223321 http://cr.openjdk.java.net/~kcr/8223321/webrev.00/ Once reviewed, Andy can include this in the next version of the webrev (and we'll update the CSR). -- Kevin On 5/3/2019 10:23 AM,

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

Andy, I've created the following CRs to track the findings: https://bugs.openjdk.java.net/browse/JDK-8223325 https://bugs.openjdk.java.net/browse/JDK-8223323 - Alexey On 5/2/2019 5:08 PM, Andy Herrick wrote: Alexey: Please file Bugs for these two issues. /Andy On 5/2/2019 1:49 PM, Alexey

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

Thanks for your feedback. I filed two issues [1][2] for the thread concurrency issue. The first one needs to be solved for JDK 13, which is to either document the existing limitation (which is probably what we'll do) or serialize access by synchronizing on the JPackageToolProvider class (or,

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

Thanks for your feedback. I filed two issues [1][2] for the thread concurrency issue. The first one needs to be solved for JDK 13, which is to either document the existing limitation (which is probably what we'll do) or serialize access by synchronizing on the JPackageToolProvider class (or,

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

Hi Scott, I agree this a good option. Though we still need to create some custom wix source code for shortcuts, so we can't get rid completely of Java code generating wix sources. - Alexey On 5/2/2019 8:54 PM, Scott Palmer wrote: Ideally the wix code should be generated by running the

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

Hi Alexander, I'll file cleanup issues (or add to existing bugs) for the rest. Thanks. -- Kevin On 5/2/2019 6:33 PM, Alexander Matveev wrote: Hi Kevin, See below. On 5/2/2019 5:38 PM, Kevin Rushforth wrote: Here are a few follow-on comments. As with my earlier comments, none of these

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

Hi Kevin, See below. On 5/2/2019 5:38 PM, Kevin Rushforth wrote: Here are a few follow-on comments. As with my earlier comments, none of these need to be addressed prior to integration. 1. I found a few more classes that do I/O and could benefit from using try-with-resources:    IOUtils,

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

Ideally the wix code should be generated by running the heat.exe tool on the application image. Scott > On May 2, 2019, at 5:08 PM, Andy Herrick wrote: > > Alexey: > > Please file Bugs for these two issues. > > /Andy > > >> On 5/2/2019 1:49 PM, Alexey Semenyuk wrote: >> Some findings: >>

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

Here are a few follow-on comments. As with my earlier comments, none of these need to be addressed prior to integration. 1. I found a few more classes that do I/O and could benefit from using try-with-resources:    IOUtils, LinuxAppImageBuilder, LinuxDebBundler, LinuxRpmBundler,

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

Alexey: Please file Bugs for these two issues. /Andy On 5/2/2019 1:49 PM, Alexey Semenyuk wrote: Some findings: http://cr.openjdk.java.net/~herrick/8212780/webrev.ea6/raw_files/new/make/launcher/Launcher-jdk.jpackage.gmk: I think definitions of BUILD_JPACKAGE_APPLAUNCHEREXE and

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

JDK-8223264 has been filed to address this. /Andy On 5/2/2019 2:25 PM, Phil Race wrote: Although our build system doesn't complain, my local Linux gcc generates several warnings which prevent jpackage from building. The attached patch makes

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

Semyon: Although we removed --mac-app-store-entitlements and --mac-app-store-category options from help text, and disabled the mac-app-store target (so these two options have no effect) when we decided to drop support for this in the the initial release, we never actually removed the

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

Although our build system doesn't complain, my local Linux gcc generates several warnings which prevent jpackage from building. The attached patch makes it happy. There are several of these :- jpackage/open/src/jdk.jpackage/share/native/libapplauncher/IniFile.cpp: In member function

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

Some findings: http://cr.openjdk.java.net/~herrick/8212780/webrev.ea6/raw_files/new/make/launcher/Launcher-jdk.jpackage.gmk: I think definitions of BUILD_JPACKAGE_APPLAUNCHEREXE and BUILD_JPACKAGE_APPLAUNCHERWEXE targets should be moved to

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

The --mac-app-store-entitlements option was only used for the Mac App Store deployment. Since it is not supported anymore this option is not used anywhere and need to be removed. Also the jdk.jpackage.internal. MacAppStoreBundler class and related resources are the dead code. --Semyon On

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

Hi, Some comments, a initial batch... Having support for the ToolProvider is great. However, there is no indication about whether it is valid to use it from multiple threads. The implementation is structured to be deliberately single thread use only with the invocation being via a static

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

I filed JDK-8223241 to address each of these issues, and included import statement wildcard usage as suggested (removing it from JDK-8223189 ) /Andy On 5/1/2019 7:17 PM, Kevin Rushforth

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

I got most of the way through the platform-independent Java code today. Here is my feedback so far. NOTE: I don't think any of these need to be addressed prior to integration, so you can either fix them in a follow-on webrev or file a bug for fixing after integration. GENERAL: * Several

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

I have filed JDK-8223189 to address these. /Andy On 4/30/2019 7:02 PM, Kevin Rushforth wrote: I have a couple nit-picky comments: 1. The change to src/jdk.jlink/share/classes/module-info.java is unrelated to jpackage and should be

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

I filed task JDK-8223187 to look into (1) and CR JDK-8223188 to address (2). /Andy On 4/30/2019 6:53 PM, Phil Race wrote: A couple of questions / observations :- 1) setlocale

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

Hi Andy, Looks good overall. http://cr.openjdk.java.net/~herrick/8212780/webrev.ea6/src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/Info-lite.plist.template.html

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

I have a couple nit-picky comments: 1. The change to src/jdk.jlink/share/classes/module-info.java is unrelated to jpackage and should be reverted (there is only a white-space change and a copyright date change to that file) 2. The following files have whitespace errors that will cause

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

A couple of questions / observations :- 1) setlocale http://cr.openjdk.java.net/~herrick/8212780/webrev.ea6/src/jdk.jpackage/linux/native/jpackageapplauncher/launcher.cpp.html 52 int main(int argc, char *argv[]) { 53 int result = 1; 54 setlocale(LC_ALL, "en_US.utf8"); Why is this

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

jpackage reviewers: We hope to move JEP 343 to "Proposed to Target" next week, so we would like expedite the review process as much as possible. The total change is huge, so I am including the below descriptions of some of the central and important classes included: jdk.jpackage.main.Main:

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

On 4/29/2019 12:21 PM, Erik Joelsson wrote: There is a new set of macros that should be used to check things like target OS. The new macro is called like this: ifeq ($(call isTargetOs, windows macosx linux), false) Lib-jdk.jpackage.gmk and Launcher-jdk.jpackage.gmk: Same thing with

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

Hello, We did review build changes as they were done in the sandbox, but IMO this change needs a fresh review now since some things have changed in the build since those reviews took place. CompileJavaModules.gmk: The -parameters flag to javac is currently only used for jdk.aot and

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

Adding build-dev for the build changes. I don't know if these were previously reviewed there, but I am not sure what the changes in NativeCompilation.gmk have to do with jpackage. -phil. On 4/24/19, 5:47 PM, Andy Herrick wrote: On 4/24/2019 8:44 PM, Andy Herrick wrote: Please review

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

On 4/24/2019 8:44 PM, Andy Herrick wrote: Please review  changes for [1] which is the implementation bug for JEP-343. The webrev at [2] is the total cumulative webrev of changes for the jpackage tool, currently in the JDK-8200758-branch branch of the open sandbox repository. The webrev

RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

Please review  changes for [1] which is the implementation bug for JEP-343. The webrev at [2] is the total cumulative webrev of changes for the jpackage tool, currently in the JDK-8200758-branch branch of the open sandbox repository. The webrev at [3] shows the changes from EA-05 to EA-06.

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation (update 2)

On 1/27/2019 4:55 AM, Alan Bateman wrote: On 11/01/2019 19:41, Andy Herrick wrote: This is the second update to the Request For Review of the implementation of the Java Packager Tool (jpackager) as described in JEP 343: Packaging Tool I've

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation (update 2)

On 11/01/2019 19:41, Andy Herrick wrote: This is the second update to the Request For Review of the implementation of the Java Packager Tool (jpackager) as described in JEP 343: Packaging Tool I've started to play with the latest EA build,

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation (update 2)

On 2019-01-17 16:06, Andy Herrick wrote: If I remove the line -nologo from lib-jdk.jpackage.gmk: 69 LDFLAGS_windows := -nologo, \ I get the logo during build (same with console andnon-console version): Microsoft (R) Incremental Linker Version 14.12.25835.0 Copyright (C) Microsoft

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation (update 2)

If I remove the line -nologo from lib-jdk.jpackage.gmk: 69 LDFLAGS_windows := -nologo, \ I get the logo during build (same with console andnon-console version): Microsoft (R) Incremental Linker Version 14.12.25835.0 Copyright (C) Microsoft Corporation.  All rights reserved. do I need

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation (update 2)

Hi Andy, This is looking really sweet from a build perspective! Just a few minor nits: * In Launcher-jdk.jpackage.gmk, please indent the else clause ("$(eval $(call SetupBuildLauncher, jpackage ") two spaces. * In Lib-jdk.jpackage.gmk, I think there's still room to prune some more

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation (update 2)

yes On 1/13/2019 2:50 PM, Alan Bateman wrote: On 11/01/2019 19:41, Andy Herrick wrote: This is the second update to the Request For Review of the implementation of the Java Packager Tool (jpackager) as described in JEP 343: Packaging Tool

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation (update 2)

On 11/01/2019 19:41, Andy Herrick wrote: This is the second update to the Request For Review of the implementation of the Java Packager Tool (jpackager) as described in JEP 343: Packaging Tool You're making great progress. Is the table of CLI

RFR: JDK-8212780: JEP 343: Packaging Tool Implementation (update 2)

This is the second update to the Request For Review of the implementation of the Java Packager Tool (jpackager) as described in JEP 343: Packaging Tool This webrev corresponds to the second EA build, Build 8 (2019/1/8), posted at

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

The help output of jpackager should mention how to set the classpath for the various bundle resource files. I have not found a working solution how to set the classpath. jpackager -classpath build/deploy/ jpackager -cp build/deploy/ DEB Using default package resource [menu icon] (add

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

On 11/10/2018 8:12 AM, Sverre Moe wrote: I have been using the jpackager that Johan Vos backported for OpenJDK 11. For this I have some points of improvement I would like to mention. 1) The control file for debian package does not set correct description --name test --description This is a

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

Hi, Does --limit-modules work as intended, are there any tests? With a command such as: jpackager -Djlink.debug=true create-image \     --input out/artifacts \     --output out \     --limit-modules java.base \     --main-jar Hello-jar/Hello.jar \     --class Main It complains that: Exception:

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

Hi, On 11/14/2018 09:52 AM, Andy Herrick wrote: On 11/13/2018 5:50 PM, Philip Race wrote: On 11/13/18, 12:52 PM, Roger Riggs wrote: Hi, There are enough files unique to each platform to put them in separate packages otherwise you get too many (IMHO) files in a single package/directory

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

On 11/13/2018 5:50 PM, Philip Race wrote: On 11/13/18, 12:52 PM, Roger Riggs wrote: Hi, There are enough files unique to each platform to put them in separate packages otherwise you get too many (IMHO) files in a single package/directory and its harder to tell which go with which.  There

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

On 11/13/18, 12:52 PM, Roger Riggs wrote: Hi, There are enough files unique to each platform to put them in separate packages otherwise you get too many (IMHO) files in a single package/directory and its harder to tell which go with which. There isn't much of a problem with classes

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

Hello, May I chime in a little on the jpackager. I have been using it with OpenJDK 11, as backported by Johan Vos from Gluon. It has worked fine, but I have noticed some flaws. 1) The control file for DEB package does not set correct description --name test --description This is a Test

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

On 11/13/2018 4:08 PM, Roger Riggs wrote: Hi, A few high level comments: The JDK already has a command option parser (JoptSimple) in the module jdk.internal.opt and the System Logger.  Why not use them for the argument parsing and logging? We have an RFE to convert argument parsing to

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

Hi, A few high level comments: The JDK already has a command option parser (JoptSimple) in the module jdk.internal.opt and the System Logger.  Why not use them for the argument parsing and logging? Similarly, we've been encouraging developers to use the java.nio.file APIs and get away from

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

I agree with this and would take it further. 1 file is in ./share/classes/jdk/jpackager/internal/builders - why not just ./share/classes/jdk/jpackager/internal 2 files are in ./share/classes/jdk/jpackager/internal/bundlers - why not just in ./share/classes/jdk/jpackager/internal 1 file is

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

Question .. why is "mac", "linux" and "windows" necessary in the package name here ?  src/jdk.jpackager/macosx/classes/jdk/jpackager/internal/mac/MacAppBundler.java   src/jdk.jpackager/windows/classes/jdk/jpackager/internal/builders/windows/WindowsAppImageBuilder.java

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

On 11/13/2018 3:39 AM, Alan Bateman wrote: On 12/11/2018 21:40, Philip Race wrote:   74   75 static String getTmpDir() {   76 String os = System.getProperty("os.name").toLowerCase();   77 if (os.contains("win")) {   78 return System.getProperty("user.home")   79 

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

On 11/12/2018 6:36 PM, Alan Snyder wrote: Can someone say whether the two-step package creation feature is implemented and explain how to use it? Yes - 1.) "jpackager create-image -o output -n app-name ..." 2.) "jpackager create-installer -o installer-output -n installer-name --app-image

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

Yes - The intent of getTmpDir() here is to match the GetTempDirectory() in launcher, which this does for the three supported platforms, but there is no need to check for the unsupported platforms. I will clean this up as you suggest as part ofJDK-8213756

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

On 12/11/2018 21:40, Philip Race wrote:   74   75 static String getTmpDir() {   76 String os = System.getProperty("os.name").toLowerCase();   77 if (os.contains("win")) {   78 return System.getProperty("user.home")   79 +

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

://bernd.eckenfels.net Von: core-libs-dev im Auftrag von Philip Race Gesendet: Montag, November 12, 2018 10:55 PM An: Andy Herrick Cc: build-dev; core-libs-dev@openjdk.java.net Betreff: Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation 74 75 static String getTmpDir

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

Can someone say whether the two-step package creation feature is implemented and explain how to use it? What is the plan for documentation? The command line help is inadequate. > On Oct 26, 2018, at 1:09 PM, Alan Snyder wrote: > > I noticed the following statement in the JEP: > > In this

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

BTW there were also a few minor grammar issues in javadoc eg 41 * the option named "-singleton" must be specified on jpackager command line. "the jpackager" 84 * Registers {@code SingleInstanceListener} for current process. and 96 * Registers {@code SingleInstanceListener}

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

On 11/12/2018 4:54 PM, Philip Race wrote: On 11/12/18, 1:45 PM, Andy Herrick wrote: On 11/12/2018 3:22 PM, Philip Race wrote: Adding build-dev back .. I noticed that module jdk.jpackager.runtime requires java.desktop on all platforms So far as I can tell this is for a Mac-only support

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

On 11/12/18, 1:45 PM, Andy Herrick wrote: On 11/12/2018 3:22 PM, Philip Race wrote: Adding build-dev back .. I noticed that module jdk.jpackager.runtime requires java.desktop on all platforms So far as I can tell this is for a Mac-only support for receiving and handling file open events.

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

On 11/12/2018 3:22 PM, Philip Race wrote: Adding build-dev back .. I noticed that module jdk.jpackager.runtime requires java.desktop on all platforms So far as I can tell this is for a Mac-only support for receiving and handling file open events. Probably it only makes sense or gets used

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

74 75 static String getTmpDir() { 76 String os = System.getProperty("os.name").toLowerCase(); 77 if (os.contains("win")) { 78 return System.getProperty("user.home") 79 + "\\AppData\\LocalLow\\Sun\\Java\\JPackager\\tmp"; 80

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

SingleInstanceService. registerSingleInstance() says If the {@code SingleInstanceListener} object is already registered, or 98 * {@code slistener} is {@code null}, then the registration is skipped. I don't see how that can be working as every call to registerSingleInstanceForId creates

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

Adding build-dev back .. I noticed that module jdk.jpackager.runtime requires java.desktop on all platforms So far as I can tell this is for a Mac-only support for receiving and handling file open events. Probably it only makes sense or gets used when the API is used from a running desktop

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

On 11/9/2018 5:25 PM, Andy Herrick wrote: This is an update to the Request For Review of the implementation of the Java Packager Tool (jpackager) as described in JEP 343: Packaging Tool This refresh renames the packages used to jdk.jpackager

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

I have been using the jpackager that Johan Vos backported for OpenJDK 11. For this I have some points of improvement I would like to mention. 1) The control file for debian package does not set correct description --name test --description This is a Test Application

RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

This is an update to the Request For Review of the implementation of the Java Packager Tool (jpackager) as described in JEP 343: Packaging Tool This refresh renames the packages used to jdk.jpackager and jdk.jpackager.runtime, removes the

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

Based on feedback and further discussion, we're going with jdk.jpackager and jdk.jpackager.runtime. I’m also hoping that the service daemon support will make it into the JDK 12 deliverable. Is that out of the question at this point? It won't make JDK 12, but is near the top of the list for

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

On Oct 30, 2018, at 1:10 PM, Andy Herrick wrote: > > On 10/30/2018 12:09 PM, Alan Bateman wrote: >>> ... >> Alex has suggested jdk.jpackager to avoid giving the impression that it's >> the "JDK packager". Also several existing tool modules have the tool name in >> the module name (jdk.jdeps,

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

On 2018-10-24 19:18, Erik Joelsson wrote: Hello, Nice to see this finally happening! Are we actually adding a new demo? I thought we were working towards getting rid of the demos completely. CompileJavaModules.gmk: The jdk.packager_CLEAN_FILES could be replaced with a simple

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

On 10/30/2018 10:11 AM, Andy Herrick wrote: On 10/24/2018 10:22 AM, Alan Bateman wrote: On 23/10/2018 16:49, Andy Herrick wrote: This patch implements the Java Packager Tool (jpackager) as described in JEP 343: Packaging Tool jpackager

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

On 10/30/2018 12:09 PM, Alan Bateman wrote: On 30/10/2018 14:11, Andy Herrick wrote: : What is the status of the JNLPConverter tool? I see it is included as a "demo" but maybe it would be better to host somewhere else as this is for developers migrating Java Web Start applications. Our

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

inline On 10/30/2018 9:09 AM, Alan Bateman wrote: On 30/10/2018 14:11, Andy Herrick wrote: : If I read the webrev correctly then it adds two modules, one with the jpackager tool and the other with an API. It would be useful to get a bit more information on the split. Also I think the name

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

On 30/10/2018 14:11, Andy Herrick wrote: : What is the status of the JNLPConverter tool? I see it is included as a "demo" but maybe it would be better to host somewhere else as this is for developers migrating Java Web Start applications. Our current plan is to deliver it only as a demo.

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

On 10/24/2018 10:22 AM, Alan Bateman wrote: On 23/10/2018 16:49, Andy Herrick wrote: This patch implements the Java Packager Tool (jpackager) as described in JEP 343: Packaging Tool jpackager is a simple packaging tool, based on the

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

I noticed the following statement in the JEP: In this latter case, the tool can either create a native package from a previously created application image, or it can create a native package directly. I cannot tell from the command summary whether this option has been implemented or not.

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

Andy added the a comment [1] to the JEP with the command line options. I'll format it and add it to the JEP itself soon, but until then you can see it in the comments to help you review it. The tests will come shortly (Andy can comment on the state of this). They will be a mix of automated

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

Hello, Nice to see this finally happening! Are we actually adding a new demo? I thought we were working towards getting rid of the demos completely. CompileJavaModules.gmk: The jdk.packager_CLEAN_FILES could be replaced with a simple "jdk.packager_CLEAN := .properties" unless you actually

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

On 23/10/2018 16:49, Andy Herrick wrote: This patch implements the Java Packager Tool (jpackager) as described in JEP 343: Packaging Tool jpackager is a simple packaging tool, based on the JavaFX |javapackager| tool, that:  * Supports

  1   2   >