from:"Alexey Semenyuk"

Re: Prototype of jpackager in jdk/sandbox [was: Draft JEP proposal: JDK-8200758: Packaging Tool]

2018-07-25 Thread Alexey Semenyuk


Jörg,

I don't think it will be very much work to bring service bundler code from JFX 
packager into OpenJDK jpackager. Though I can't give you estimates on amount of 
work needed to be done for this at the moment.

- Alexey


On 7/23/2018 7:47 AM, Buchberger, Joerg wrote:

Thanks for the insight.

@Alexey: Then, how much work do you see in reactivating service bundler?

Cheers
Jörg



-Original Message-
From: Kevin Rushforth [mailto:kevin.rushfo...@oracle.com]
Sent: Donnerstag, 12. Juli 2018 01:09
To: Buchberger, Joerg ; 
core-libs-dev@openjdk.java.net
Cc: Alexey Semenyuk ; Andy Herrick 

Subject: Re: Prototype of jpackager in jdk/sandbox [was: Draft JEP proposal: 
JDK-8200758: Packaging Tool]

We will likely be able to deliver the .exe installer (with its dependency on 
Inno Setup).

As for the service bundler, this will be a "nice to have" (a stretch
goal) for this version, but isn't on the list of committed features.
Alexsei might be able to comment further on how much work it would be to 
provide it, including documenting and testing it. This might give you, and 
other interested developers, a sense of how likely this is to make it for this 
version.

-- Kevin


On 7/10/2018 4:35 AM, Buchberger, Joerg wrote:

Hi

thanks for the update/info. I had a quick look at the changes. So, here some 
thoughts...

As described in JDK-8200758, and therefore expected, WinExeBundler has been 
removed in favor of putting focus on WinMsiBundler.
(Although, I regret that decision - since my personal experience has
been that InnoSetup based WinExeBundler has worked much better than
wix based WinMsiBundler for our use cases - I can live with that.)

What is much more disturbing: WinServiceBundler has also been actively removed, 
although that was working fine together with both wix/msi and exe/iss. Why has 
service wrapping been removed as well, while the command line option for it is 
kept in place?

Is there any chance of service bundler coming back into scope of JDK-8200758 or 
coming back in at all?

Cheers
Jörg


-Original Message-
From: core-libs-dev [mailto:core-libs-dev-boun...@openjdk.java.net] On
Behalf Of Kevin Rushforth
Sent: Freitag, 6. Juli 2018 22:14
To: core-libs-dev@openjdk.java.net
Cc: Alexey Semenyuk ; Andy Herrick

Subject: Prototype of jpackager in jdk/sandbox [was: Draft JEP
proposal: JDK-8200758: Packaging Tool]

An initial prototype of the jpackager tool has been pushed to a new 
'JDK-8200758-branch' branch in the JDK sandbox [1]. If anyone is interested in 
taking a look, you can clone it as follows:

       hg clone 
https://urldefense.proofpoint.com/v2/url?u=http-3A__hg.openjdk.java.net_jdk_sandbox=DwIFaQ=uD3W7j5M6i1jDeSybgeVwm110GaiTFmxRW_bPSUkfEI=iA565f2Lw9W7rluKs5jkpPnslpNKVsvq0dJJKhVEy_Q=7aoiG26qKHqhAG4Ry-hOl_c8cZ2UdmcCtrya0JOnsgg=jWWENz_KIkmyh-9-kQQvoZ0BwBymwQ-BKx8hG3F5Iy0=
       cd ./sandbox
       hg update JDK-8200758-branch

I plan to reply to the feedback already provided, and update the JEP [2] next 
week some time, but in the mean time if you have additional questions or 
comments, feel free to reply.

-- Kevin

[1]
https://urldefense.proofpoint.com/v2/url?u=http-3A__hg.openjdk.java.ne
t_jdk_sandbox_shortlog_JDK-2D8200758-2Dbranch=DwIFaQ=uD3W7j5M6i1jD
eSybgeVwm110GaiTFmxRW_bPSUkfEI=iA565f2Lw9W7rluKs5jkpPnslpNKVsvq0dJJK
hVEy_Q=7aoiG26qKHqhAG4Ry-hOl_c8cZ2UdmcCtrya0JOnsgg=F-CqPAWlz-Cfb0k
ae2FBEj4Ncd3ZBVu7BeOVY1AM-cA= [2]
https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java
.net_browse_JDK-2D8200758=DwIFaQ=uD3W7j5M6i1jDeSybgeVwm110GaiTFmxR
W_bPSUkfEI=iA565f2Lw9W7rluKs5jkpPnslpNKVsvq0dJJKhVEy_Q=7aoiG26qKHq
hAG4Ry-hOl_c8cZ2UdmcCtrya0JOnsgg=DFIAHtCR1o--KMLuBzurIzx5MDu67NgtUrE
dQ22wI9I=


On 6/27/2018 3:30 PM, Kevin Rushforth wrote:

We're aiming to get this into JDK 12 early enough so that an EA build
would be available around the time JDK 11 ships. That will allow you
to take a jlinked image with JDK 11 and package it up using (the EA)
jpackager.

We will create a development branch in the JDK sandbox [1] some time
in the next week or so so you can follow the development.

Also, thank you to those who have provided feedback. I'll reply to
feedback soon and then incorporate it into an updated JEP.

-- Kevin

Re: RFR: JDK-8221582: Rename jvm-args option to java-options

2019-03-28 Thread Alexey Semenyuk


Andy,

IMHO if you are renaming defines in C++ code, it makes sense to rename 
variables/functions too:
JVMArgs -> JavaArgs in 
http://cr.openjdk.java.net/~herrick/8221582/webrev.02/src/jdk.jpackage/share/native/libapplauncher/Helpers.cpp.sdiff.html
Package::ReadJVMArgs -> Package::ReadJavaArgs in 
http://cr.openjdk.java.net/~herrick/8221582/webrev.02/src/jdk.jpackage/share/native/libapplauncher/Package.cpp.sdiff.html


In general it would make sense to rename JVMArgs in JavaArgs:
---
ASEMENYU-LAP+asemenyu@ASEMENYU-LAP 
/cygdrive/c/ade/work/as/jds/work/10_sandbox/jdk10/open/src/jdk.jpackage

$ find . -name '*.cpp' -o -name '*.h' | xargs.exe grep JVMArgs
./share/native/libapplauncher/Helpers.cpp: 
Helpers::GetJVMArgsFromConfig(IPropertyContainer* config) {
./share/native/libapplauncher/Helpers.cpp: OrderedMap 
JVMArgs =
./share/native/libapplauncher/Helpers.cpp: 
Helpers::GetJVMArgsFromConfig();
./share/native/libapplauncher/Helpers.cpp: 
Container->AppendSection(keys[CONFIG_SECTION_JVMOPTIONS], JVMArgs);
./share/native/libapplauncher/Helpers.h: 
GetJVMArgsFromConfig(IPropertyContainer* config);
./share/native/libapplauncher/JavaVirtualMachine.cpp: 
options.AppendValues(package.GetJVMArgs());

./share/native/libapplauncher/Package.cpp:    ReadJVMArgs(config);
./share/native/libapplauncher/Package.cpp:void 
Package::ReadJVMArgs(ISectionalPropertyContainer* Config) {

./share/native/libapplauncher/Package.cpp: FBootFields->FJVMArgs);
./share/native/libapplauncher/Package.cpp: FBootFields->FJVMArgs);
./share/native/libapplauncher/Package.cpp: FBootFields->FJVMArgs);
./share/native/libapplauncher/Package.cpp:OrderedMap 
Package::GetJVMArgs() {

./share/native/libapplauncher/Package.cpp:    return FBootFields->FJVMArgs;
./share/native/libapplauncher/Package.h:    OrderedMap 
FJVMArgs;
./share/native/libapplauncher/Package.h:    void 
ReadJVMArgs(ISectionalPropertyContainer* Config);
./share/native/libapplauncher/Package.h:    OrderedMap 
GetJVMArgs();

---

- Alexey

On 3/28/2019 7:07 AM, Andy Herrick wrote:

RFR: JDK-8221582: Rename jvm-args option to java-options

Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).


[1] - https://bugs.openjdk.java.net/browse/JDK-8221582

[2] - http://cr.openjdk.java.net/~herrick/8221582/

/Andy

Re: RFR: JDK-8221582: Rename jvm-args option to java-options

2019-03-28 Thread Alexey Semenyuk

Agreed. Would you like me to create a record to track this follow up 
clean up?


- Alexey

On 3/28/2019 2:01 PM, Andy Herrick wrote:



On 3/28/2019 1:54 PM, Kevin Rushforth wrote:
That seems like a good cleanup. It could be done in a follow-on bug 
depending on what Andy wants to do.



Yes - I think we should file this as a follow on fix.
My main concern first was the public facing names, but as with other 
modified options, it would be best to go back and clean all internal 
names to reflect the current naming.


/Andy


-- Kevin


On 3/28/2019 10:50 AM, Alexey Semenyuk wrote:

Andy,

IMHO if you are renaming defines in C++ code, it makes sense to 
rename variables/functions too:
JVMArgs -> JavaArgs in 
http://cr.openjdk.java.net/~herrick/8221582/webrev.02/src/jdk.jpackage/share/native/libapplauncher/Helpers.cpp.sdiff.html
Package::ReadJVMArgs -> Package::ReadJavaArgs in 
http://cr.openjdk.java.net/~herrick/8221582/webrev.02/src/jdk.jpackage/share/native/libapplauncher/Package.cpp.sdiff.html


In general it would make sense to rename JVMArgs in JavaArgs:
---
ASEMENYU-LAP+asemenyu@ASEMENYU-LAP 
/cygdrive/c/ade/work/as/jds/work/10_sandbox/jdk10/open/src/jdk.jpackage

$ find . -name '*.cpp' -o -name '*.h' | xargs.exe grep JVMArgs
./share/native/libapplauncher/Helpers.cpp: 
Helpers::GetJVMArgsFromConfig(IPropertyContainer* config) {
./share/native/libapplauncher/Helpers.cpp: OrderedMapTString> JVMArgs =
./share/native/libapplauncher/Helpers.cpp: 
Helpers::GetJVMArgsFromConfig();
./share/native/libapplauncher/Helpers.cpp: 
Container->AppendSection(keys[CONFIG_SECTION_JVMOPTIONS], JVMArgs);
./share/native/libapplauncher/Helpers.h: 
GetJVMArgsFromConfig(IPropertyContainer* config);
./share/native/libapplauncher/JavaVirtualMachine.cpp: 
options.AppendValues(package.GetJVMArgs());

./share/native/libapplauncher/Package.cpp: ReadJVMArgs(config);
./share/native/libapplauncher/Package.cpp:void 
Package::ReadJVMArgs(ISectionalPropertyContainer* Config) {

./share/native/libapplauncher/Package.cpp: FBootFields->FJVMArgs);
./share/native/libapplauncher/Package.cpp: FBootFields->FJVMArgs);
./share/native/libapplauncher/Package.cpp: FBootFields->FJVMArgs);
./share/native/libapplauncher/Package.cpp:OrderedMapTString> Package::GetJVMArgs() {
./share/native/libapplauncher/Package.cpp:    return 
FBootFields->FJVMArgs;
./share/native/libapplauncher/Package.h: OrderedMapTString> FJVMArgs;
./share/native/libapplauncher/Package.h:    void 
ReadJVMArgs(ISectionalPropertyContainer* Config);
./share/native/libapplauncher/Package.h: OrderedMapTString> GetJVMArgs();

---

- Alexey

On 3/28/2019 7:07 AM, Andy Herrick wrote:

RFR: JDK-8221582: Rename jvm-args option to java-options

Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).


[1] - https://bugs.openjdk.java.net/browse/JDK-8221582

[2] - http://cr.openjdk.java.net/~herrick/8221582/

/Andy

jpackage Proposal to replace Inno Setup in exe installers for Windows

2019-03-26 Thread Alexey Semenyuk


Hi,

RFE for jpackage to replace Inno Setup in exe installers for Windows was 
filed recently and available at 
https://bugs.openjdk.java.net/browse/JDK-8221333.
RFE was filed based on an assumption it will not have a major impact on 
users of jpackage. Please let us know in the comments to the RFE if 
there are any objections against the change.


- Alexey

Re: RFR: JDK-8224597: create automated tests for platform create-app-image options

2019-06-07 Thread Alexey Semenyuk

Not quite exactly what I meant by suggesting to use xml api. Sorry for 
not being specific. With DOM and Xpath this can be as simple as the 
following:

---
package sample;

import java.io.FileInputStream;
import javax.xml.parsers.DocumentBuilder;
import javax.xml.parsers.DocumentBuilderFactory;
import javax.xml.xpath.XPath;
import javax.xml.xpath.XPathConstants;
import javax.xml.xpath.XPathFactory;

public class Sample {
    public static void main(String[] args) throws Exception {
    DocumentBuilder b = 
DocumentBuilderFactory.newDefaultInstance().newDocumentBuilder();

    org.w3c.dom.Document doc = b.parse(new FileInputStream(args[0]));

    XPath xPath = XPathFactory.newInstance().newXPath();
    // Query for the value of  element preceding  element
    // with value equal to CFBundleIdentifier
    String v = 
(String)xPath.evaluate("//string[preceding-sibling::key = 
\"CFBundleIdentifier\"][1]", doc, XPathConstants.STRING);


    if (!v.equals(args[1])) {
    throw new AssertionError("Unexpected value of 
CFBundleIdentifier key: [" + v + "]. Expected value: [" + args[1] + "]");

    }
    }
}
---

Running the sample:
java sample.Sample 
jp_sandbox\jdk\open\src\jdk.jpackage\macosx\classes\jdk\jpackage\internal\resources\Info-lite.plist.template 
foo
Exception in thread "main" java.lang.AssertionError: Unexpected value of 
CFBundleIdentifier key: [DEPLOY_BUNDLE_IDENTIFIER]. Expected value: [foo]

    at sample.Sample.main(Sample.java:25)

java sample.Sample 
jp_sandbox\jdk\open\src\jdk.jpackage\macosx\classes\jdk\jpackage\internal\resources\Info-lite.plist.templateDEPLOY_BUNDLE_IDENTIFIER


- Alexey

On 6/6/2019 10:56 PM, Alexander Matveev wrote:

http://cr.openjdk.java.net/~almatvee/8224597/webrev.02/

Updated OS X tests to use XML APIs to parse Info.plist.

Thanks,
Alexander

On 6/6/2019 2:43 PM, Alexey Semenyuk wrote:

Any particular reason not to use xml api to read xml files?
The way to extract app attributes from xml files produced by jpackage 
looks fragile.


- Alexey

On 6/6/2019 5:37 PM, Alexander Matveev wrote:

Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).


- Added tests for --win-console, --mac-bundle-identifier and 
--mac-bundle-name.


[1] https://bugs.openjdk.java.net/browse/JDK-8224597
[2] http://cr.openjdk.java.net/~almatvee/8224597/webrev.00/

Thanks,
Alexander

Re: RFR: JDK-8224130: create additional automated tests for create-app-image

2019-06-06 Thread Alexey Semenyuk


Looks good.

- Alexey

On 6/6/2019 5:45 PM, Andy Herrick wrote:
revised to use Files.newBufferedWriter() in 
JPackageHelper.cmdWithAtFilename() as suggested.


webrev: http://cr.openjdk.java.net/~herrick/8224130/webrev.02/

/Andy


On 6/6/2019 1:03 PM, Alexey Semenyuk wrote:
http://cr.openjdk.java.net/~herrick/8224130/webrev.01/test/jdk/tools/jpackage/helpers/JPackageHelper.java.sdiff.html: 


---
 try (PrintWriter out = new PrintWriter(new BufferedWriter(
 520 new FileWriter("argfile.cmds" {
 521 out.println(fileString);
 522 }
---
I suggest to use Files.newBufferedWriter() call instead of new 
BufferedWriter(new FileWriter...)).


-Alexey

On 6/5/2019 8:07 PM, Andy Herrick wrote:

Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).


[1] https://bugs.openjdk.java.net/browse/JDK-8224130
[2] http://cr.openjdk.java.net/~herrick/8224130/

/Andy

Re: RFR: JDK-8222901: different behavior when --name option not used

2019-06-06 Thread Alexey Semenyuk


Looks good.

- Alexey

On 6/5/2019 7:52 PM, Andy Herrick wrote:

Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).


[1] https://bugs.openjdk.java.net/browse/JDK-8222901
[2] http://cr.openjdk.java.net/~herrick/8222901

/Andy

Re: RFR: JDK-8223241: jpackage cleanup from code review

2019-06-06 Thread Alexey Semenyuk


Looks good.

- Alexey

On 6/5/2019 8:01 PM, Andy Herrick wrote:

Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).


[1] https://bugs.openjdk.java.net/browse/JDK-8223241
[2] http://cr.openjdk.java.net/~herrick/8223241/

/Andy

Re: RFR: JDK-8223953: Fix CLASSPATH parsing for sub-directorys containing spaces

2019-06-06 Thread Alexey Semenyuk


Looks good.

- Alexey

On 6/5/2019 8:03 PM, Andy Herrick wrote:

Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).


[1] https://bugs.openjdk.java.net/browse/JDK-8223953
[2] http://cr.openjdk.java.net/~herrick/8223953/

/Andy

Re: RFR: JDK-8224748: --add-launcher option --add-modules

2019-06-06 Thread Alexey Semenyuk


Looks good.

- Alexey

On 6/5/2019 8:06 PM, Andy Herrick wrote:

Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).


[1] https://bugs.openjdk.java.net/browse/JDK-8224748
[2] http://cr.openjdk.java.net/~herrick/8224748/

/Andy

Re: RFR: JDK-8223212: Code cleanup found during jpackage review

2019-06-06 Thread Alexey Semenyuk


Looks good.

- Alexey

On 6/5/2019 8:14 PM, Andy Herrick wrote:

Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).


[1] https://bugs.openjdk.java.net/browse/JDK-8223212
[2] http://cr.openjdk.java.net/~herrick/8223212/

/Andy

Re: RFR: JDK-8224130: create additional automated tests for create-app-image

2019-06-06 Thread Alexey Semenyuk


http://cr.openjdk.java.net/~herrick/8224130/webrev.01/test/jdk/tools/jpackage/helpers/JPackageHelper.java.sdiff.html:
---
 try (PrintWriter out = new PrintWriter(new BufferedWriter(
 520 new FileWriter("argfile.cmds" {
 521 out.println(fileString);
 522 }
---
I suggest to use Files.newBufferedWriter() call instead of new 
BufferedWriter(new FileWriter...)).


-Alexey

On 6/5/2019 8:07 PM, Andy Herrick wrote:

Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).


[1] https://bugs.openjdk.java.net/browse/JDK-8224130
[2] http://cr.openjdk.java.net/~herrick/8224130/

/Andy

Re: RFR: JDK-8223333: Use try-with-resources where feasible

2019-06-06 Thread Alexey Semenyuk

http://cr.openjdk.java.net/~herrick/822/webrev.02/src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacCertificate.java.sdiff.html, 
lines 81-93 can be replaced with a single statement, something like:

---
java.nio.file.Files.copy(
  new ByteArrayInputStream(baos.toByteArray()),
  output.toPath(),
  StandardCopyOption.REPLACE_EXISTING);
---

- Alexey

On 6/5/2019 7:54 PM, Andy Herrick wrote:

Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).


[1] https://bugs.openjdk.java.net/browse/JDK-822
[2] http://cr.openjdk.java.net/~herrick/822/

/Andy

Re: RFR: JDK-8223586: remove jpackage dead code and other cleanup

2019-06-06 Thread Alexey Semenyuk


Looks good.

- Alexey

On 6/5/2019 8:14 PM, Andy Herrick wrote:

Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).


[1] https://bugs.openjdk.java.net/browse/JDK-8223586
[2] http://cr.openjdk.java.net/~herrick/8223586/

/Andy

Re: RFR: JDK-8224597: create automated tests for platform create-app-image options

2019-06-06 Thread Alexey Semenyuk


Any particular reason not to use xml api to read xml files?
The way to extract app attributes from xml files produced by jpackage 
looks fragile.


- Alexey

On 6/6/2019 5:37 PM, Alexander Matveev wrote:

Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).


- Added tests for --win-console, --mac-bundle-identifier and 
--mac-bundle-name.


[1] https://bugs.openjdk.java.net/browse/JDK-8224597
[2] http://cr.openjdk.java.net/~almatvee/8224597/webrev.00/

Thanks,
Alexander

Re: RFR: JDK-8223333: Use try-with-resources where feasible

2019-06-06 Thread Alexey Semenyuk


Looks good.

- Alexey

On 6/6/2019 3:48 PM, Andy Herrick wrote:

OK - revised MacCertificate as per below:

webrev: http://cr.openjdk.java.net/~herrick/822/webrev.03

/Andy

On 6/6/2019 12:47 PM, Alexey Semenyuk wrote:
http://cr.openjdk.java.net/~herrick/822/webrev.02/src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacCertificate.java.sdiff.html, 
lines 81-93 can be replaced with a single statement, something like:

---
java.nio.file.Files.copy(
  new ByteArrayInputStream(baos.toByteArray()),
  output.toPath(),
  StandardCopyOption.REPLACE_EXISTING);
---

- Alexey

On 6/5/2019 7:54 PM, Andy Herrick wrote:

Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).


[1] https://bugs.openjdk.java.net/browse/JDK-822
[2] http://cr.openjdk.java.net/~herrick/822/

/Andy

Re: RFR: JDK-8225569: jpackage app-image layout

2019-06-14 Thread Alexey Semenyuk


Looks good.

- Alexey

On 6/14/2019 10:17 AM, Andy Herrick wrote:

Please review the revised jpackage fix [3] for issue [1]

revised to use Path.of() in JPackagePath test helper and to centralize 
code that creates output dirs and/or makes sure they are empty and 
writable.


[3] http://cr.openjdk.java.net/~herrick/8225569/webrev.02/


/Andy

On 6/13/2019 1:21 PM, Andy Herrick wrote:


Sorry - subject was missing, this is for: JDK-8225569: jpackage 
app-image layout


/Andy

On 6/13/2019 12:59 PM, Andy Herrick wrote:

Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).


[1] https://bugs.openjdk.java.net/browse/JDK-8225569
[2] http://cr.openjdk.java.net/~herrick/8225569/webrev.01/ 



/Andy

RFR: JDK-8221333: Replace Inno Setup with custom MSI wrapper for .exe bundler

2019-06-14 Thread Alexey Semenyuk


Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox
repository (jpackage).

- Get rid of dependency on Inno Setup for .exe installers on Windows 
platform.


[1] https://bugs.openjdk.java.net/browse/JDK-8221333

[2] http://cr.openjdk.java.net/~asemenyuk/8221333/webrev.00/

Thanks,
Alexey

Re: RFR: JDK-8221333: Replace Inno Setup with custom MSI wrapper for .exe bundler

2019-06-14 Thread Alexey Semenyuk


Andy,

Thank you for the review!

- Alexey

On 6/14/2019 4:29 PM, Andy Herrick wrote:



On 6/14/19, 3:45 PM, Andy Herrick wrote:
I imported this patch , and after some merging problems, built 
jpackager.


a simple exe installer built with:


$JDK_HOME/bin/jpackage create-installer \
--installer-type exe \
--input ../input-jars \
--output output \
--name test-exe \
--vendor "Oracle Test" \
--description "Test exe installer" \
--win-menu \
--main-jar hello.jar \
--main-class hello \
worked fine. (I could run the installer and then launch test-exe from 
the windows menu.)


but a jre installer run with :


$JDK_HOME/bin/jpackage create-installer \
--installer-type exe \
--output output \
--name java-sandbox \
--runtime-image jdk13 \
--app-version 14.0 \

works fine too.

but using --license-text arg:


$JDK_HOME/bin/jpackage create-installer \
--installer-type exe \
--output output \
--name java-sandbox \
--runtime-image jdk13 \
--app-version 13.0 \
--license-file license.txt \


causes an error:

java.io.IOException: Exec failed with code 103 command 
[[C:\cygwin\home\aherrick\devtools\wix\light.exe, -nologo, -spdb, 
-sice:60, 
C:\cygwin\tmp\jdk.jpackage6069689087804197124\tmp\java-sandbox.wixobj, 
-ext, WixUtilExtension, -ext, WixUIExtension, -loc, 
C:\cygwin\tmp\jdk.jpackage6069689087804197124\config\MsiInstallerStrings_en.wxl, 
-out, 
C:\cygwin\tmp\jdk.jpackage6069689087804197124\images\win-exe.image\java-sandbox-13.0.msi] 
in C:\cygwin\home\aherrick\packager\windows\jdk13


This may be unrelated bug - I get the same error using 
--installer-type msi -- but should be filed and investigated.


Yes - this in unrelated - I get this problem with unaltered sandbox. - 
I will file and fix.


/Andy



otherwise I think this change is good to go.

/Andy






On 6/14/2019 1:09 PM, Alexey Semenyuk wrote:

Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox
repository (jpackage).

- Get rid of dependency on Inno Setup for .exe installers on Windows 
platform.


[1] https://bugs.openjdk.java.net/browse/JDK-8221333

[2] http://cr.openjdk.java.net/~asemenyuk/8221333/webrev.00/

Thanks,
Alexey

Re: RFR: JDK-8226193: BundleNameTest and BundleIdentifierTest fails if run without network connection

2019-06-14 Thread Alexey Semenyuk


Looks good!

- Alexey

On 6/14/2019 6:42 PM, Alexander Matveev wrote:

Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).


- Fixed by disabling loading external DTD files.

[1] https://bugs.openjdk.java.net/browse/JDK-8226193
[2] http://cr.openjdk.java.net/~almatvee/8226193/webrev.00

Thanks,
Alexander

Re: RFR: JDK-8224597: create automated tests for platform create-app-image options

2019-06-10 Thread Alexey Semenyuk

I agree that SAX/StAX are faster and more memory efficient compared to 
DOM. But the use case is just to query a string from 2Kb XML file. in 
this scenario use of DOM+XPath results in less coding with a tiny 
performance degradation. Does this sound reasonable?


- Alexey

On 6/7/2019 7:09 PM, Semyon Sadetsky wrote:

On 6/7/19 9:52 AM, Alexey Semenyuk wrote:

Not quite exactly what I meant by suggesting to use xml api. Sorry 
for not being specific. With DOM and Xpath this can be as simple as 
the following:


XPath is DOM based = slow. That point is not clear.

--Semyon



---
package sample;

import java.io.FileInputStream;
import javax.xml.parsers.DocumentBuilder;
import javax.xml.parsers.DocumentBuilderFactory;
import javax.xml.xpath.XPath;
import javax.xml.xpath.XPathConstants;
import javax.xml.xpath.XPathFactory;

public class Sample {
    public static void main(String[] args) throws Exception {
    DocumentBuilder b = 
DocumentBuilderFactory.newDefaultInstance().newDocumentBuilder();
    org.w3c.dom.Document doc = b.parse(new 
FileInputStream(args[0]));


    XPath xPath = XPathFactory.newInstance().newXPath();
    // Query for the value of  element preceding  
element

    // with value equal to CFBundleIdentifier
    String v = 
(String)xPath.evaluate("//string[preceding-sibling::key = 
\"CFBundleIdentifier\"][1]", doc, XPathConstants.STRING);


    if (!v.equals(args[1])) {
    throw new AssertionError("Unexpected value of 
CFBundleIdentifier key: [" + v + "]. Expected value: [" + args[1] + 
"]");

    }
    }
}
---

Running the sample:
java sample.Sample 
jp_sandbox\jdk\open\src\jdk.jpackage\macosx\classes\jdk\jpackage\internal\resources\Info-lite.plist.template 
foo
Exception in thread "main" java.lang.AssertionError: Unexpected value 
of CFBundleIdentifier key: [DEPLOY_BUNDLE_IDENTIFIER]. Expected 
value: [foo]

    at sample.Sample.main(Sample.java:25)

java sample.Sample 
jp_sandbox\jdk\open\src\jdk.jpackage\macosx\classes\jdk\jpackage\internal\resources\Info-lite.plist.templateDEPLOY_BUNDLE_IDENTIFIER


- Alexey

On 6/6/2019 10:56 PM, Alexander Matveev wrote:

http://cr.openjdk.java.net/~almatvee/8224597/webrev.02/

Updated OS X tests to use XML APIs to parse Info.plist.

Thanks,
Alexander

On 6/6/2019 2:43 PM, Alexey Semenyuk wrote:

Any particular reason not to use xml api to read xml files?
The way to extract app attributes from xml files produced by 
jpackage looks fragile.


- Alexey

On 6/6/2019 5:37 PM, Alexander Matveev wrote:

Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open 
sandbox repository (jpackage).


- Added tests for --win-console, --mac-bundle-identifier and 
--mac-bundle-name.


[1] https://bugs.openjdk.java.net/browse/JDK-8224597
[2] http://cr.openjdk.java.net/~almatvee/8224597/webrev.00/

Thanks,
Alexander

Re: RFR: JDK-8224486: Arguments from jpackager cfg file not processed correctly

2019-06-25 Thread Alexey Semenyuk

In 
http://cr.openjdk.java.net/~almatvee/8224486/webrev.00/src/jdk.jpackage/share/native/libapplauncher/JavaVirtualMachine.cpp.sdiff.html, 
JavaOptions::AppendValues(), why do we need branching based on the 
result of Values.GetAllowDuplicates()? Why can't we use the same logic 
that was introduced by your patch to read values from the map in which 
duplicate keys are not allowed?


- Alexey

On 6/24/2019 9:18 PM, Alexander Matveev wrote:

Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).


- Duplicated Java options were not read correctly from OrderedMap, 
instead we read only unique from map. Fixed by reading duplicated Java 
options.


[1] https://bugs.openjdk.java.net/browse/JDK-8224486
[2] http://cr.openjdk.java.net/~almatvee/8224486/webrev.00/

Thanks,
Alexander

Re: RFR: JDK-8225569: jpackage app-image layout

2019-06-13 Thread Alexey Semenyuk


Andy,

I was just curios why we don't use Paths. If we should then I'll use 
this API in my patches. I didn't mean to ask you do the clean up in all 
the sources :)


- Alexey

On 6/13/2019 3:34 PM, Andy Herrick wrote:



On 6/13/19, 2:00 PM, Alexey Semenyuk wrote:

Looks good.

Q: any good reason we are not using
Paths.get(a, b, c)
instead of
a + File.separator + b + File.separator + c
to build paths?
There are a lot of places we should be using Paths instead of String 
and File objects, but JPackagePath (test helper) is among the worst of 
the offenders.  I will make a pass at cleaning that up and any other 
such places this change set is touching.


/Andy


- Alexey

On 6/13/2019 1:21 PM, Andy Herrick wrote:


Sorry - subject was missing, this is for: JDK-8225569: jpackage 
app-image layout


/Andy

On 6/13/2019 12:59 PM, Andy Herrick wrote:

Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).


[1] https://bugs.openjdk.java.net/browse/JDK-8225569
[2] http://cr.openjdk.java.net/~herrick/8225569/webrev.01/ 
<http://cr.openjdk.java.net/%7Eherrick/8225569/webrev.01/>


/Andy

Re: RFR: JDK-8225569: jpackage app-image layout

2019-06-13 Thread Alexey Semenyuk


Looks good.

Q: any good reason we are not using
Paths.get(a, b, c)
instead of
a + File.separator + b + File.separator + c
to build paths?

- Alexey

On 6/13/2019 1:21 PM, Andy Herrick wrote:


Sorry - subject was missing, this is for: JDK-8225569: jpackage 
app-image layout


/Andy

On 6/13/2019 12:59 PM, Andy Herrick wrote:

Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).


[1] https://bugs.openjdk.java.net/browse/JDK-8225569
[2] http://cr.openjdk.java.net/~herrick/8225569/webrev.01/ 



/Andy

Re: RFR: JDK-8225428: CLI change to remove "mode", rename to "package", and build only one target

2019-06-19 Thread Alexey Semenyuk


http://cr.openjdk.java.net/~herrick/8225428/webrev.01/test/jdk/tools/jpackage/JPackageMissingArgumentsTest.java.sdiff.html:
---
private static final String [] RESULT_7 = {"--module-path", 
"--runtime-image", "app-image"};

---
Should it be "--app-image"?

- Alexey

On 6/19/2019 1:34 PM, Andy Herrick wrote:

Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).


JDK-8225428: CLI change to remove "mode", rename to "package", and 
build only one target


[1] https://bugs.openjdk.java.net/browse/JDK-8225428

[2] http://cr.openjdk.java.net/~herrick/8225428/webrev.01/ 



/Andy

Re: RFR: JDK-8225428: CLI change to remove "mode", rename to "package", and build only one target

2019-06-20 Thread Alexey Semenyuk


Looks good.

- Alexey

On 6/20/2019 12:54 PM, Andy Herrick wrote:

On 6/19/2019 1:34 PM, Andy Herrick wrote:

Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).


JDK-8225428: CLI change to remove "mode", rename to "package", and 
build only one target


[1] https://bugs.openjdk.java.net/browse/JDK-8225428

[2] http://cr.openjdk.java.net/~herrick/8225428/webrev.01/
/Andy


Minor revision [3] of help and message text in response to feedback:

[3] http://cr.openjdk.java.net/~herrick/8225428/webrev.02/

/Andy

Re: RFR: JDK-8226532: cleanup is not called when jpackage command fails.

2019-06-21 Thread Alexey Semenyuk


Looks good

- Alexey

On 6/21/2019 9:01 AM, Andy Herrick wrote:

Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).


Trivial fix to clean up the temp directory created by jpackage.

[1] https://bugs.openjdk.java.net/browse/JDK-8226532

[2] http://cr.openjdk.java.net/~herrick/8226532/

/Andy

RFR: JDK-8223643: Provide better defined context for custom installer steps on Windows

2019-05-23 Thread Alexey Semenyuk


Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).


src\jdk.jpackage\windows\classes\jdk\jpackage\internal\WinMsiBundler.java:
 - code running candle.exe on WiX sources reworked. Before the fix 
template.wxs file was used in text substitution with application 
specific strings and the result file was passed to candel.exe command 
line. With this patch application specific data is saved in WiX 
variables that are put on candle.exe command line and candle.exe runs on 
main.wxs that is used as is. Sample candle.exe command line:

---
Running [C:\Program Files (x86)\WiX Toolset v3.11\bin\candle.exe, 
-nologo, 
C:\cygwin64\tmp\jdk.jpackage1414148896269938282\config\GuiTest.wxs, 
-ext, WixUtilExtension, -out, 
C:\cygwin64\tmp\jdk.jpackage1414148896269938282\tmp\GuiTest.wixobj, 
-dJpAppDescription=GuiTest, -dJpAppVersion=1.0, 
-dJpWixVersion36OrNewer=yes, 
-dJpProductCode=36784cc6-d050-4852-ac67-2f7de7c0b292, 
-dJpAppName=GuiTest, 
-dJpProductUpgradeCode=4f3374fd-f78a-4ffb-96f8-d5412bcca95f, 
-dJpIsSystemWide=yes, -dJpAppVendor=Unknown, 
-dJpConfigDir=C:\cygwin64\tmp\jdk.jpackage1414148896269938282\config] in 
C:\cygwin64\tmp\jdk.jpackage1414148896269938282\images\win-msi.image\GuiTest

GuiTest.wxs
---
 - high level description of what WinMsiBundler class does is 
documented in class comment. Meaning of WiX variables defined by 
jpackage on candle.exe command line documented as well. Main Wix source 
used by jpackage (main.wxs) and a set of WiX variables defined by 
jpackage should be considered as a public interface for custom 
extensions of WiX installers produced by jpackage;


- fix error when r/o non rtf file is passed with --license command line 
option (line 459).


test\jdk\tools\jpackage\createinstaller\windows:
 - added tests for runtime installer. Like all jpackage tests that 
depend on running platform specific packaging tools (WiX Toolkit, 
rpmbuild, etc.) the new tests come with @ignore tag.


src\jdk.jpackage\share\classes\jdk\jpackage\main\CommandLine.java:
 - fix javadoc errors and make the class package private.

src\jdk.jpackage\windows\classes\jdk\jpackage\internal\resources\WinResources.properties, 
MsiInstallerStrings_en.wxl:
 - move "message.install.dir.exist" string from .properties file to 
corresponding .wxl file. Reason: this string is referenced only from 
installers generated by jpackage, not in jpackage itself. All localized 
strings used in installers should be stored in .wxl files and not in 
.properties files.


src\jdk.jpackage\windows\classes\jdk\jpackage\internal\resources\template.wxs, 
main.wxs:
 - rename template.wxs into main.wxs and make it a valid WiX source 
that doesn't require preliminary text substitution.


[1] https://bugs.openjdk.java.net/browse/JDK-8223643

[2] http://cr.openjdk.java.net/~asemenyuk/8223643/webrev.00/

Thanks,
Alexey

RFR: JDK-8224222: Inno setup 6 broke jpackage

2019-05-20 Thread Alexey Semenyuk


Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox
repository (jpackage).

- Improve code detecting version of Inno Setup to make it work with Inno 
Setup v6 updates.


[1] https://bugs.openjdk.java.net/browse/JDK-8224222

[2] http://cr.openjdk.java.net/~asemenyuk/8224222/webrev.00/

Thanks,
Alexey

Re: RFR: JDK-8224222: Inno setup 6 broke jpackage

2019-05-20 Thread Alexey Semenyuk


Alexander,

I tried running other .exe from ISS install dir. They don't output 
anything meaningful.

File version for all .exe files in ISS install dir is "0.0.0.0".
Running isscc.exe without arguments doesn't output version number.
Running isscc.exe with the empty project file was the only option that I 
found working.


- Alexey

On 5/20/2019 6:07 PM, Alexander Matveev wrote:

Hi Alexey,

Is there better way to figure out InnoSetup version? Creating empty 
project file seems complicated.

If there no such way, then fix looks fine.

Thanks,
Alexander

On 5/20/2019 8:27 AM, Alexey Semenyuk wrote:

Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox
repository (jpackage).

- Improve code detecting version of Inno Setup to make it work with 
Inno Setup v6 updates.


[1] https://bugs.openjdk.java.net/browse/JDK-8224222

[2] http://cr.openjdk.java.net/~asemenyuk/8224222/webrev.00/

Thanks,
Alexey

Re: jpackage producing non-working binaries on Windows

2019-05-01 Thread Alexey Semenyuk


Hi Tom,

What is your jpackage command line? Could you please rerun it with 
JPACKAGE_DEBUG environment variable set to "true".


- Alexey

On 4/30/2019 11:15 AM, Tom Anderson wrote:

Hello,

I am trying out the early-access jpackage tool. It works perfectly on 
Linux, but on Windows produces a binary which does not do anything 
when run.


I would like to either fix any error i have made, or help you identify 
a bug, if there is one!


Is this the right place to come with this problem? If not, where 
should i go? Is there a list of known issues other than on the 
download page [1]? What debugging steps should i try? Would a 
self-contained example be helpful to you? What other information would 
you like?


Regards,
tom

[1] https://jdk.java.net/jpackage/

Re: jpackage producing non-working binaries on Windows

2019-05-02 Thread Alexey Semenyuk


Hi Tom,

Thank for providing a reference to the demo project and build output.

In your example you use jpackage to produce an application image, not an 
exe or msi installers. Just to be clear on the test scenario.


Test app prints "Hello, world!" to stdout as far as I can tell from 
https://github.com/tomwhoiscontrary/jpackage-demo/blob/master/src/main/java/demo/App.java
I think I understand why there is no output when the app is launched by 
executable produced by jpackage. To make stdout and stderr streams work 
as expected Windows application should explicitly allocate a console by 
calling corresponding win api or be linked as console app. None is the 
case with executables produced by jpackage. This looks like a bug.


If you have something like
---
package demo;

import javax.swing.*;

public class App {
    public static void main(String args[]){
    JFrame frame = new JFrame("My First GUI");
    frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
    frame.setSize(300,300);
    JButton button1 = new JButton("Press");
    frame.getContentPane().add(button1);
    frame.setVisible(true);
    }
}
---

in your test app you should see some output though.

- Alexey

On 5/2/2019 7:14 AM, Tom Anderson wrote:

Hi Alexey,

Here is a demo project:

https://github.com/tomwhoiscontrary/jpackage-demo

If i run this on Windows (Windows 10 in a VM), it produces this output:

https://gist.github.com/tomwhoiscontrary/ee33dda3c124d8a67bd5bba5b8d5e32d

Which includes the following command line:

[create-app-image, --name, demo, --input, 
C:\Users\IEUser\Downloads\jpackage-demo-master\jpackage-demo-master\build\libs, 
--output, 
C:\Users\IEUser\Downloads\jpackage-demo-master\jpackage-demo-master\build/app-image, 
--main-jar, jpackage-demo.jar]


I should note that i am running the build using JDK 11, then using the 
early access JDK 13 only to run jpackage at the end.


Regards,
tom

On Wed, 1 May 2019, Alexey Semenyuk wrote:


Hi Tom,

What is your jpackage command line? Could you please rerun it with 
JPACKAGE_DEBUG environment variable set to "true".


- Alexey

On 4/30/2019 11:15 AM, Tom Anderson wrote:

Hello,

I am trying out the early-access jpackage tool. It works perfectly 
on Linux, but on Windows produces a binary which does not do 
anything when run.


I would like to either fix any error i have made, or help you 
identify a bug, if there is one!


Is this the right place to come with this problem? If not, where 
should i go? Is there a list of known issues other than on the 
download page [1]? What debugging steps should i try? Would a 
self-contained example be helpful to you? What other information 
would you like?


Regards,
tom

[1] https://jdk.java.net/jpackage/

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

2019-05-02 Thread Alexey Semenyuk

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
http://cr.openjdk.java.net/~herrick/8212780/webrev.ea6/make/lib/Lib-jdk.jpackage.gmk.html.
Reason: these targets don't output executables into images/jdk/bin
directory. They produce artifacts that stored as resources in jpackage
just like other targets defined in Lib-jdk.jpackage.gmk.

---
$ less config/bundle.wxi | grep 'http://cr.openjdk.java.net/~herrick/8212780/webrev.ea6/src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WinMsiBundler.java.html:745
+ " Guid=\"" + UUID.randomUUID().toString() + "\""
Use of random GUIDs for components is not recommended and potentially
can result in issues with application updates. The recommended approach
is to generate stable GUIDs -
http://wixtoolset.org/documentation/manual/v3/howtos/general/generate_guids.html,
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/How-does-heat-maintain-consistent-GUIDs-td7599757.html.
Algorithm to create stable GUIDs is explained at
https://tools.ietf.org/html/rfc4122#page-13. However we can avoid the
hassle of generating stable GUIDs if we would put only one file in every
component. In this case WiX is able to generate stable GUIDs for us.

- Alexey

On 4/27/2019 8:46 PM, Philip Race wrote:
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 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.
sorry - the links are reversed from what is stated above. [2] is the
incremental webrev since EA 05, [3] is the cumulativewebrev

/Andy

The latest EA-6 (build 49) is posted at [4].

Please send feedback to core-libs-dev@openjdk.java.net

[1] https://bugs.openjdk.java.net/browse/JDK-8200758

[2] http://cr.openjdk.java.net/~herrick/8212780/webrev.05-06/

[3] http://cr.openjdk.java.net/~herrick/8212780/webrev.ea6/

[4] http://jdk.java.net/jpackage/

/Andy

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

2019-05-03 Thread Alexey Semenyuk

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 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:

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
http://cr.openjdk.java.net/~herrick/8212780/webrev.ea6/make/lib/Lib-jdk.jpackage.gmk.html.
Reason: these targets don't output executables into images/jdk/bin directory.
They produce artifacts that stored as resources in jpackage just like other
targets defined in Lib-jdk.jpackage.gmk.

Wix source code produced by
http://cr.openjdk.java.net/~herrick/8212780/webrev.ea6/src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WinMsiBundler.java.html
doesn't comply to recommendations of how files should be packed in component.
The recommendation is to use one file per a component -
http://wixtoolset.org/documentation/manual/v3/howtos/files_and_registry/add_a_file.html.
However jpackage produces way less components than files:
---
$ less config/bundle.wxi | grep 'http://cr.openjdk.java.net/~herrick/8212780/webrev.ea6/src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WinMsiBundler.java.html:745
+ " Guid=\"" + UUID.randomUUID().toString() + "\""
Use of random GUIDs for components is not recommended and potentially can
result in issues with application updates. The recommended approach is to
generate stable GUIDs -
http://wixtoolset.org/documentation/manual/v3/howtos/general/generate_guids.html,

http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/How-does-heat-maintain-consistent-GUIDs-td7599757.html.
Algorithm to create stable GUIDs is explained at
https://tools.ietf.org/html/rfc4122#page-13. However we can avoid the hassle of
generating stable GUIDs if we would put only one file in every component. In
this case WiX is able to generate stable GUIDs for us.

- Alexey

On 4/27/2019 8:46 PM, Philip Race wrote:
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 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.

sorry - the links are reversed from what is stated above. [2] is the
incremental webrev since EA 05, [3] is the cumulativewebrev
/Andy

The latest EA-6 (build 49) is posted at [4].

Please send feedback to core-libs-dev@openjdk.java.net

[1] https://bugs.openjdk.java.net/browse/JDK-8200758

[2] http://cr.openjdk.java.net/~herrick/8212780/webrev.05-06/

[3] http://cr.openjdk.java.net/~herrick/8212780/webrev.ea6/

[4] http://jdk.java.net/jpackage/

/Andy

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

2019-05-03 Thread Alexey Semenyuk

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 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
BUILD_JPACKAGE_APPLAUNCHERWEXE targets should be moved to
http://cr.openjdk.java.net/~herrick/8212780/webrev.ea6/make/lib/Lib-jdk.jpackage.gmk.html.
Reason: these targets don't output executables into images/jdk/bin
directory. They produce artifacts that stored as resources in
jpackage just like other targets defined in Lib-jdk.jpackage.gmk.

---
$ less config/bundle.wxi | grep 'http://cr.openjdk.java.net/~herrick/8212780/webrev.ea6/src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WinMsiBundler.java.html:745

+ " Guid=\"" + UUID.randomUUID().toString() + "\""
Use of random GUIDs for components is not recommended and potentially
can result in issues with application updates. The recommended
approach is to generate stable GUIDs -
http://wixtoolset.org/documentation/manual/v3/howtos/general/generate_guids.html,
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/How-does-heat-maintain-consistent-GUIDs-td7599757.html.

Algorithm to create stable GUIDs is explained at
https://tools.ietf.org/html/rfc4122#page-13. However we can avoid the
hassle of generating stable GUIDs if we would put only one file in
every component. In this case WiX is able to generate stable GUIDs
for us.

- Alexey

-phil.

On 4/24/19, 5:47 PM, Andy Herrick wrote:

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 at [3] shows the changes from EA-05 to EA-06.
sorry - the links are reversed from what is stated above. [2] is
the incremental webrev since EA 05, [3] is the cumulativewebrev

/Andy

The latest EA-6 (build 49) is posted at [4].

Please send feedback to core-libs-dev@openjdk.java.net

[1] https://bugs.openjdk.java.net/browse/JDK-8200758

[2] http://cr.openjdk.java.net/~herrick/8212780/webrev.05-06/

[3] http://cr.openjdk.java.net/~herrick/8212780/webrev.ea6/

[4] http://jdk.java.net/jpackage/

/Andy

RFR: JDK-8226835: Command window pops up building exe package

2019-06-27 Thread Alexey Semenyuk


Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).


- Eliminate unexpected console window in .exe installers on Windows 
platform.


[1] https://bugs.openjdk.java.net/browse/JDK-8226835

[2] http://cr.openjdk.java.net/~asemenyuk/8226835/webrev.00/

Thanks,
Alexey

Re: JPackage EA build 8 ( jdk-14-jpackage+1-8 )

2019-06-26 Thread Alexey Semenyuk


Bug ID is JDK-8226835.

- Alexey

On 6/26/2019 2:52 PM, Andy Herrick wrote:
We need to investigate this further, I have created issue: JDK-8221333 
to track this issue.


Thank you for you feedback.

/Andy


On 6/25/2019 9:17 AM, Rachel Greenham wrote:
I've been getting the new jpackage working with our project build. 
Generally everything's fine. One probable minor bug relating to 
JDK-8221333:  Replace Inno Setup with custom MSI wrapper for .exe 
bundler:


The generated EXE installer, when run from eg: file explorer or 
browser downloads dialog, also opens a blank command window behind 
the installer's own window, which I'm pretty sure Inno Setup 
generated installers didn't do. Can this be avoided? (Is there a 
possibly-insufficiently-documented option involved, or is it just a 
bug?) Otherwise it's basically working so it's just a cosmetic 
untidyness. No, the --win-console option is not being used, besides 
which this is the *installer* that's affected, not the actual 
application once installed. This also (probably unsurprisingly) 
doesn't affect the MSI installer.

Re: RFR: JDK-8220807: excessive verbose output when running with --win-per-user-install

2019-07-12 Thread Alexey Semenyuk


Andy,

The fix suppresses warning for system wide installations too,not just 
for per user. Is this by intention?


- Alexey

On 7/12/2019 10:31 AM, Andy Herrick wrote:

Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).


[1] https://bugs.openjdk.java.net/browse/JDK-8220807

[2] http://cr.openjdk.java.net/~herrick/8220807/

/Andy

Re: RFR: JDK-8226599 use code coverage results to remove dead code

2019-06-26 Thread Alexey Semenyuk


Looks good.

- Alexey

On 6/26/2019 7:09 PM, Andy Herrick wrote:

Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).



[1] https://bugs.openjdk.java.net/browse/JDK-8226599

[2] http://cr.openjdk.java.net/~herrick/8226599/webrev.03

/Andy

Re: RFR: JDK-8220807: excessive verbose output when running with --win-per-user-install

2019-07-15 Thread Alexey Semenyuk


Looks good.

- Alexey

On 7/15/2019 7:48 AM, Andy Herrick wrote:
revised [3] to only suppress these warnings when 
--win-per-user-install option used


[3] http://cr.openjdk.java.net/~herrick/8220807/webrev.02/

/Andy

On 7/12/2019 1:22 PM, Alexey Semenyuk wrote:

Andy,

The fix suppresses warning for system wide installations too,not just 
for per user. Is this by intention?


- Alexey

On 7/12/2019 10:31 AM, Andy Herrick wrote:

Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).


[1] https://bugs.openjdk.java.net/browse/JDK-8220807

[2] http://cr.openjdk.java.net/~herrick/8220807/

/Andy

Re: RFR: JDK-8226751: "Exception: ..." for missing file

2019-07-01 Thread Alexey Semenyuk


Looks good.

On 7/1/2019 1:07 PM, Andy Herrick wrote:
Updated webrev at 
https://bugs.openjdk.java.net/browse/JDK-8226751/webrev.02 to use 
Files.isReadable()


/Andy


On 6/29/2019 9:54 AM, Kevin Rushforth wrote:
The rest of the CommandLine class uses nio Paths/Files, so the 
following might be a better fit, and also checks whether the file can 
be read:


    if (!Files.isReadable(Paths.of(name)))

The rest looks fine.

-- Kevin

On 6/29/2019 6:27 AM, Andy Herrick wrote:

Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).


[1] https://bugs.openjdk.java.net/browse/JDK-8226751

[2] http://cr.openjdk.java.net/~herrick/8226751/ 



/Andy

Re: RFR: JDK-8226904: current working directory wrong running jpackage app

2019-06-28 Thread Alexey Semenyuk


Looks good.

- Alexey

On 6/28/2019 1:59 PM, Andy Herrick wrote:

Please review the jpackage fix for bug [1] at [2].


This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).


[1] https://bugs.openjdk.java.net/browse/JDK-8226904

[2] http://cr.openjdk.java.net/~herrick/8226904/webrev.01/

/Andy

Re: RFR: JDK-8226534: combination of windows options cause exception in MsiBundler

2019-08-13 Thread Alexey Semenyuk


Looks good.

- Alexey

On 8/12/2019 8:38 PM, Alexander Matveev wrote:

Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).


- Fixed by adding --install-dir folders to RemoveFile table as per 
Wixs requirements.


[1] https://bugs.openjdk.java.net/browse/JDK-8226534

[2] http://cr.openjdk.java.net/~almatvee/8226534/webrev.00/

Thanks,
Alexander

Re: RFR: JDK-8227172: revert JDK-8225569 on windows

2019-08-12 Thread Alexey Semenyuk


Looks good.

- Alexey

On 8/10/2019 6:44 AM, Andy Herrick wrote:

Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).


This change will remove the "bin" directory on windows and revert to 
putting the executable(s) directly in output root dir. (dir>/)


[1] https://bugs.openjdk.java.net/browse/JDK-8227172

[2] http://cr.openjdk.java.net/~herrick/8227172/webrev.01/

/Andy

RFR: JDK-8215447: Investigate if current implementation of --license-file is correct for RPM packagesI

2019-08-13 Thread Alexey Semenyuk


Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).


- Install license file in the correct location in stead of the app's 
installation directory, update corresponding jtreg tests.


[1] https://bugs.openjdk.java.net/browse/JDK-8215447

[2] http://cr.openjdk.java.net/~asemenyuk/8215447/webrev.00/

Thanks,
Alexey

Re: RFR: JDK-8229138: Add --linux-app-release option for DEB and RPM packages

2019-08-13 Thread Alexey Semenyuk


Looks good.

- Alexey

On 8/13/2019 3:56 PM, Andy Herrick wrote:

Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).


[1] https://bugs.openjdk.java.net/browse/JDK-8229138?filter=-1

[2] http://cr.openjdk.java.net/~herrick/8229138/webrev.01/


Thanks,

Andy

Re: JDK-8229786: No output after WinShortcutTest.exe is launched

2019-08-16 Thread Alexey Semenyuk


Makes sense. Looks good then.

- Alexey

On 8/16/2019 3:08 PM, Andy Herrick wrote:

On 8/16/2019 2:26 PM, Alexey Semenyuk wrote:

Andy,

I think we want this change in all Windows jtreg tests as they all 
use this windowless Hello test.


yes - but except for testing launching app from shortcut of the 
installed app, the automated tests run the app and capture it's 
output, so only on these cases is--win-console arg needed to confirm 
the operation (creation of a shortcut by installer) succeeded.


/Andy


- Alexey

On 8/16/2019 2:22 PM, Andy Herrick wrote:

Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).


[1] https://bugs.openjdk.java.net/browse/JDK-8229786

[2] http://cr.openjdk.java.net/~herrick/8229786


Thanks,

Andy

RFR: JDK-8213941: Debian linux problems in JavaPackager

2019-08-16 Thread Alexey Semenyuk


Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).


- add --linux-app-category command line option

[1] https://bugs.openjdk.java.net/browse/JDK-8213941

2] http://cr.openjdk.java.net/~asemenyuk/8213941/webrev.00/

Thanks,
Alexey

Re: JDK-8229786: No output after WinShortcutTest.exe is launched

2019-08-16 Thread Alexey Semenyuk


Andy,

I think we want this change in all Windows jtreg tests as they all use 
this windowless Hello test.


- Alexey

On 8/16/2019 2:22 PM, Andy Herrick wrote:

Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).


[1] https://bugs.openjdk.java.net/browse/JDK-8229786

[2] http://cr.openjdk.java.net/~herrick/8229786


Thanks,

Andy

Re: RFR: JDK-8224594: Simplify jpackage Logging

2019-08-15 Thread Alexey Semenyuk


Looks good.

- Alexey

On 8/15/2019 4:50 PM, Andy Herrick wrote:
ok - revised [3] to restore the second trace statement (now 
Log.verbose())


[3]: http://cr.openjdk.java.net/~herrick/8224594/webrev.02/

/Andy

On 8/15/2019 3:40 PM, Andy Herrick wrote:
The first of these doesn't convey any additional information, since 
it is just parroting back the given option value.


The second may be of use, and I could restore it as a Log.verbose(), 
but I felt the output here was incomplete, and would be better served 
by tracing in the caller, since this is the value returned, and the 
caller (either MacAppBundler, MacPkgBundler, or MacAppBundler) could 
say what the key was being used for, and if the certificate derived 
from this key was valid.


In general is a fine line to decide what to include in verbose output.

We used to have both debug and verbose output, but other than 
printing out exceptions, theses two and one other were the only 
places actually calling Log.debug()


/Andy

On 8/15/2019 3:09 PM, Alexey Semenyuk wrote:

Andy,

What is the reason to remove log statements in
http://cr.openjdk.java.net/~herrick/8224594/webrev.01/src/jdk.jpackage/share/classes/jdk/jpackage/internal/StandardBundlerParam.java.sdiff.html 

http://cr.openjdk.java.net/~herrick/8224594/webrev.01/src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacBaseInstallerBundler.java.sdiff.html 



?

- Alexey

On 8/15/2019 2:53 PM, Andy Herrick wrote:

Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).


[1] https://bugs.openjdk.java.net/browse/JDK-8224594

[2] http://cr.openjdk.java.net/~herrick/8224594/


Thanks,

Andy

Re: RFR: JDK-8224594: Simplify jpackage Logging

2019-08-15 Thread Alexey Semenyuk


Sounds good.

- Alexey

On 8/15/2019 3:40 PM, Andy Herrick wrote:
The first of these doesn't convey any additional information, since it 
is just parroting back the given option value.


The second may be of use, and I could restore it as a Log.verbose(), 
but I felt the output here was incomplete, and would be better served 
by tracing in the caller, since this is the value returned, and the 
caller (either MacAppBundler, MacPkgBundler, or MacAppBundler) could 
say what the key was being used for, and if the certificate derived 
from this key was valid.


In general is a fine line to decide what to include in verbose output.

We used to have both debug and verbose output, but other than printing 
out exceptions, theses two and one other were the only places actually 
calling Log.debug()


/Andy

On 8/15/2019 3:09 PM, Alexey Semenyuk wrote:

Andy,

What is the reason to remove log statements in
http://cr.openjdk.java.net/~herrick/8224594/webrev.01/src/jdk.jpackage/share/classes/jdk/jpackage/internal/StandardBundlerParam.java.sdiff.html 

http://cr.openjdk.java.net/~herrick/8224594/webrev.01/src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacBaseInstallerBundler.java.sdiff.html 



?

- Alexey

On 8/15/2019 2:53 PM, Andy Herrick wrote:

Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).


[1] https://bugs.openjdk.java.net/browse/JDK-8224594

[2] http://cr.openjdk.java.net/~herrick/8224594/


Thanks,

Andy

Re: RFR: JDK-8224594: Simplify jpackage Logging

2019-08-15 Thread Alexey Semenyuk


Andy,

What is the reason to remove log statements in
http://cr.openjdk.java.net/~herrick/8224594/webrev.01/src/jdk.jpackage/share/classes/jdk/jpackage/internal/StandardBundlerParam.java.sdiff.html
http://cr.openjdk.java.net/~herrick/8224594/webrev.01/src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacBaseInstallerBundler.java.sdiff.html

?

- Alexey

On 8/15/2019 2:53 PM, Andy Herrick wrote:

Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).


[1] https://bugs.openjdk.java.net/browse/JDK-8224594

[2] http://cr.openjdk.java.net/~herrick/8224594/


Thanks,

Andy

RFR: JDK-8225447: Revise Debian packaging

2019-08-19 Thread Alexey Semenyuk


Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).


- fix all permission related issues reported by lintian
- cleanup control files to address issues reported by lintian
- fix jtreg tests
- change package installation directory of Debian package from 
/opt/ to /opt/ to make it compliant with Debian packaging 
requirements


Errors reported by lintian on simple test package before the fix is [3] 
and after the fix is [4]


[1] https://bugs.openjdk.java.net/browse/JDK-8225447

[2] http://cr.openjdk.java.net/~asemenyuk/8225447/webrev.00/

[3] 
http://cr.openjdk.java.net/~asemenyuk/8225447/8225447.lintian.before_the_fix.txt


[4] 
http://cr.openjdk.java.net/~asemenyuk/8225447/8225447.lintian.after_the_fix.txt


Thanks,
Alexey

Re: RFR: JDK-8229795: Investigate registry key usage and need for --win-registry-name option.

2019-08-19 Thread Alexey Semenyuk


Looks good.

Just curious why changes in FileAssociationsBase.java files?

- Alexey

On 8/19/2019 3:33 PM, Andy Herrick wrote:

Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).


[1] https://bugs.openjdk.java.net/browse/JDK-8229795

[2] http://cr.openjdk.java.net/~herrick/8229795/

/Andy

RFR: JDK-8215381: Investigate if current implementation of --license-file is correct for Debian packages

2019-08-19 Thread Alexey Semenyuk


Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).


- change format of the default copyright file to comply with Debian 
packaging requirements;
- install copyright file in proper location to comply with Debian 
packaging requirements;
- introduce --linux-deb-copyright-file command line option to allow 
override of the default copyright file template


[1] https://bugs.openjdk.java.net/browse/JDK-8215381

[2] http://cr.openjdk.java.net/~asemenyuk/8215381/webrev.00/

Thanks,
Alexey

Re: RFR: JDK-8215381: Investigate if current implementation of --license-file is correct for Debian packages

2019-08-19 Thread Alexey Semenyuk

There is a bunch or resource names with "deb-" prefix. My assumption 
about this prefix was that these names are related to control files for 
Debian packaging, i.e. special files that go into DEBIAN directory. 
copyright file used to be one of them. However this was not correct. 
There should be no DEBIAN/copyright file at all. Instead copyright file 
should be installed at /usr/share/doc//copyright location. To 
reflect this change I removed "deb-" prefix.
There is param.license-type.default resource name that is RPM specific, 
so I don't think there is any inconsistency.


- Alexey

On 8/19/2019 5:54 PM, Kevin Rushforth wrote:
Looks good. I do have one question. I see that you changed the 
resource name from "resource.deb-copyright" to 
"resource.copyright-file". Will this property be used for the RPM 
copyright / license file, too? If not, would it be better to keep 
"deb" in the name?


-- Kevin


On 8/19/2019 9:25 AM, Alexey Semenyuk wrote:

Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).


- change format of the default copyright file to comply with Debian 
packaging requirements;
- install copyright file in proper location to comply with Debian 
packaging requirements;
- introduce --linux-deb-copyright-file command line option to allow 
override of the default copyright file template


[1] https://bugs.openjdk.java.net/browse/JDK-8215381

[2] http://cr.openjdk.java.net/~asemenyuk/8215381/webrev.00/

Thanks,
Alexey

Re: RFR: JDK-8229788: Error dialog displays with DLL issue when installing WinChooserTest application

2019-08-19 Thread Alexey Semenyuk


Looks good.

BTW, we can statically link with runtime app launcher and avoid copying 
a bunch of MS dll-s to install bin directory.


- Alexey

On 8/19/2019 7:23 PM, Alexander Matveev wrote:

Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).


- Fixed by statically linking with runtime.

[1] https://bugs.openjdk.java.net/browse/JDK-8229788

[2] http://cr.openjdk.java.net/~almatvee/8229788/webrev.00/

Thanks,
Alexander

Re: RFR: JDK-8229788: Error dialog displays with DLL issue when installing WinChooserTest application

2019-08-19 Thread Alexey Semenyuk





On 8/19/2019 8:17 PM, Andy Herrick wrote:


On 8/19/2019 7:51 PM, Alexey Semenyuk wrote:

Looks good.

BTW, we can statically link with runtime app launcher and avoid 
copying a bunch of MS dll-s to install bin directory.


I'm not sure if that's true, but it would be great if it is.  The app 
launcher creates the virtual machine and runs the app in the 
launcher's process,  Wouldn't it cause a problem when the runtime and 
the app are dynamically linked ?

I don't think there will be any issues with this.

- Alexey


/Andy



- Alexey

On 8/19/2019 7:23 PM, Alexander Matveev wrote:

Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).


- Fixed by statically linking with runtime.

[1] https://bugs.openjdk.java.net/browse/JDK-8229788

[2] http://cr.openjdk.java.net/~almatvee/8229788/webrev.00/

Thanks,
Alexander

RFR: JDK-8229750: Fix bad merge of JDK-8215447 patch

2019-08-14 Thread Alexey Semenyuk


Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).


- bad merge fix

[1] https://bugs.openjdk.java.net/browse/JDK-8229750

[2] http://cr.openjdk.java.net/~asemenyuk/8229750/webrev.00/

Thanks,
Alexey

Re: RFR:JDK-8229791: Code clean up regressions

2019-08-16 Thread Alexey Semenyuk


Looks good.

- Alexey

On 8/16/2019 4:36 PM, Andy Herrick wrote:

Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).


[1] https://bugs.openjdk.java.net/browse/JDK-8229791

[2] http://cr.openjdk.java.net/~herrick/8229791/webrev.02/


Thanks,

Andy

Re: RFR: JDK-8213941: Debian linux problems in JavaPackager

2019-08-16 Thread Alexey Semenyuk

I've created https://bugs.openjdk.java.net/browse/JDK-8229840 to track 
this task.


- Alexey

On 8/16/2019 5:04 PM, Alexander Matveev wrote:

Looks good.

Is it possible to have test for this new option? If yes, then as part 
of this fix or as separate issue should be fine.


Thanks,
Alexander

On 8/16/2019 11:28 AM, Alexey Semenyuk wrote:

Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).


- add --linux-app-category command line option

[1] https://bugs.openjdk.java.net/browse/JDK-8213941

2] http://cr.openjdk.java.net/~asemenyuk/8213941/webrev.00/

Thanks,
Alexey

RFR: JDK-8228660: .deb files generated by jpackage don't follow naming convention

2019-08-27 Thread Alexey Semenyuk


Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).


- fix implementation of --linux-app-release CLI option for Debian packaging;
- use value of --linux-app-release CLI option to construct Debian 
package name.


[1] https://bugs.openjdk.java.net/browse/JDK-8228660

[2] http://cr.openjdk.java.net/~asemenyuk/8228660/webrev.03

Thanks,
Alexey

RFR: JDK-8224833: jpackages differences between platforms

2019-08-27 Thread Alexey Semenyuk


Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).


[1] https://bugs.openjdk.java.net/browse/JDK-8224833

[2] http://cr.openjdk.java.net/~asemenyuk/8224833/webrev.00/

Thanks,
Alexey

Re: RFR: JDK-8223211: Remove old code from service support

2019-08-30 Thread Alexey Semenyuk


Looks good.

- Alexey

On 8/30/2019 7:44 PM, Alexander Matveev wrote:

Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).


1) This file is not used and was removed.
2) This file was removed due to JDK-8221333.
3) Removed unused services code.

[1] https://bugs.openjdk.java.net/browse/JDK-8223211

[2] http://cr.openjdk.java.net/~almatvee/8223211/webrev.00/

Thanks,
Alexander

RFR: JDK-8229840: Add jtreg test for --linux-app-category option

2019-08-30 Thread Alexey Semenyuk


Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).


- added jtreg test for --linux-app-category option;
- added jtreg test for --linux-release option; This is to address [3] issue;
- introduced helper classes to simplify adding new jtreg tests. The 
helper classes allow to avoid code duplication between platform specific 
jpackage jtreg tests. They also allow to log actions taken by tests.

Test output for package bundle creation:
---
TRACE: assertTrue(): Check value of jpackage.test.output property 
[/home/asemenyu/jpackage_tests] references a directory
TRACE: assertTrue(): Check value of jpackage.test.output property 
[/home/asemenyu/jpackage_tests] references writable directory

TRACE: Bundler deb supported
TRACE: Execute [/home/asemenyu/work/10_sandbox/64/images/jdk/bin/javac]; 
args(3)=[-d, /tmp/jpackage_15808073035885342403, 
/media/sf_jds/work/10_sandbox/jdk10/open/test/jdk/tools/jpackage/linux/base/../../apps/image/Hello.java]...

TRACE: Done. Exit code: 0
TRACE: assertEquals(0): Check command 
[/home/asemenyu/work/10_sandbox/64/images/jdk/bin/javac]; args(3)=[-d, 
/tmp/jpackage_15808073035885342403, 
/media/sf_jds/work/10_sandbox/jdk10/open/test/jdk/tools/jpackage/linux/base/../../apps/image/Hello.java] 
exited with 0 code
TRACE: Execute [/home/asemenyu/work/10_sandbox/64/images/jdk/bin/jar]; 
args(9)=[-c, -v, -f, /tmp/jpackage_15808073035885342403/foo.jar, -e, 
Hello, -C, /tmp/jpackage_15808073035885342403, .]...

TRACE: Done. Exit code: 0
TRACE: assertEquals(0): Check command 
[/home/asemenyu/work/10_sandbox/64/images/jdk/bin/jar]; args(9)=[-c, -v, 
-f, /tmp/jpackage_15808073035885342403/foo.jar, -e, Hello, -C, 
/tmp/jpackage_15808073035885342403, .] exited with 0 code
TRACE: Execute 
[/home/asemenyu/work/10_sandbox/64/images/jdk/bin/jpackage]; 
args(14)=[--input, ./input, --output, /home/asemenyu/jpackage_tests, 
--name, ReleaseTest, --package-type, deb, --linux-app-release, Rc3, 
--main-jar, hello.jar, --main-class, Hello]...

TRACE: Done. Exit code: 0
TRACE: assertEquals(0): Check command 
[/home/asemenyu/work/10_sandbox/64/images/jdk/bin/jpackage]; 
args(14)=[--input, ./input, --output, /home/asemenyu/jpackage_tests, 
--name, ReleaseTest, --package-type, deb, --linux-app-release, Rc3, 
--main-jar, hello.jar, --main-class, Hello] exited with 0 code
TRACE: Execute [dpkg]; args(1)=[--print-architecture]; redirect output 
to [/tmp/jpackage_10813571496694787689.out]...

TRACE: Done. Exit code: 0
TRACE: assertEquals(0): Check command [dpkg]; 
args(1)=[--print-architecture] exited with 0 code
TRACE: assertTrue(): Check file 
[/home/asemenyu/jpackage_tests/releasetest_1.0-Rc3_amd64.deb] exists
TRACE: Execute [dpkg-deb]; args(3)=[-f, 
/home/asemenyu/jpackage_tests/releasetest_1.0-Rc3_amd64.deb, Version]; 
redirect output to [/tmp/jpackage_1729501500147798.out]...

TRACE: Done. Exit code: 0
TRACE: assertEquals(0): Check command [dpkg-deb]; args(3)=[-f, 
/home/asemenyu/jpackage_tests/releasetest_1.0-Rc3_amd64.deb, Version] 
exited with 0 code

TRACE: assertTrue(): Check value of Version field [1.0-Rc3] ends with Rc3
---

Test output for package installation verification:
---
TRACE: assertTrue(): Check value of jpackage.test.output property 
[/home/asemenyu/jpackage_tests] references a directory
TRACE: assertTrue(): Check value of jpackage.test.output property 
[/home/asemenyu/jpackage_tests] references writable directory

TRACE: Bundler deb supported
TRACE: Execute [dpkg]; args(1)=[--print-architecture]; redirect output 
to [/tmp/jpackage_1127921622487705754.out]...

TRACE: Done. Exit code: 0
TRACE: assertEquals(0): Check command [dpkg]; 
args(1)=[--print-architecture] exited with 0 code
TRACE: Execute [dpkg]; args(2)=[--contents, 
/home/asemenyu/jpackage_tests/releasetest_1.0-Rc3_amd64.deb]; redirect 
output to [/tmp/jpackage_16221854689490241666.out]...

TRACE: Done. Exit code: 0
TRACE: assertEquals(0): Check command [dpkg]; args(2)=[--contents, 
/home/asemenyu/jpackage_tests/releasetest_1.0-Rc3_amd64.deb] exited with 
0 code
TRACE: assertTrue(): Check application launcher 
[/opt/releasetest/bin/ReleaseTest] is a file
TRACE: assertTrue(): Check application launcher 
[/opt/releasetest/bin/ReleaseTest] can be executed
TRACE: Execute [dpkg]; args(2)=[--contents, 
/home/asemenyu/jpackage_tests/releasetest_1.0-Rc3_amd64.deb]; redirect 
output to [/tmp/jpackage_12615070579893278257.out]...

TRACE: Done. Exit code: 0
TRACE: assertEquals(0): Check command [dpkg]; args(2)=[--contents, 
/home/asemenyu/jpackage_tests/releasetest_1.0-Rc3_amd64.deb] exited with 
0 code
TRACE: Execute [/opt/releasetest/bin/ReleaseTest]; args(0)=[]; in 
directory [.]...

TRACE: Done. Exit code: 0
TRACE: assertEquals(0): Check command 
[/opt/releasetest/bin/ReleaseTest]; args(0)=[] exited with 0 code

TRACE: assertTrue(): Check file [./appOutput.txt] exists
TRACE: assertEquals(2): Check file [./appOutput.txt] contains 2 text lines

Re: RFR: JDK-8229840: Add jtreg test for --linux-app-category option

2019-08-30 Thread Alexey Semenyuk





On 8/30/2019 7:15 PM, Alexander Matveev wrote:

Hi Alexey,

Looks good. Any plans to convert all tests to use new helper classes?

Yes, of course! I plan to do this is steps:
1. Refactor Linux tests;
2. Refactor Windows tests;
3. Refactor OSX tests;

I'll cover steps 1 and 2 myself once I sort out my high priority 
jpackage assignments.

I'll need some help with step 3.

- Alexey


Thanks,
Alexander

On 8/30/2019 2:55 PM, Alexey Semenyuk wrote:

Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).


- added jtreg test for --linux-app-category option;
- added jtreg test for --linux-release option; This is to address [3] 
issue;
- introduced helper classes to simplify adding new jtreg tests. The 
helper classes allow to avoid code duplication between platform 
specific jpackage jtreg tests. They also allow to log actions taken 
by tests.

Test output for package bundle creation:
---
TRACE: assertTrue(): Check value of jpackage.test.output property 
[/home/asemenyu/jpackage_tests] references a directory
TRACE: assertTrue(): Check value of jpackage.test.output property 
[/home/asemenyu/jpackage_tests] references writable directory

TRACE: Bundler deb supported
TRACE: Execute 
[/home/asemenyu/work/10_sandbox/64/images/jdk/bin/javac]; 
args(3)=[-d, /tmp/jpackage_15808073035885342403, 
/media/sf_jds/work/10_sandbox/jdk10/open/test/jdk/tools/jpackage/linux/base/../../apps/image/Hello.java]...

TRACE: Done. Exit code: 0
TRACE: assertEquals(0): Check command 
[/home/asemenyu/work/10_sandbox/64/images/jdk/bin/javac]; 
args(3)=[-d, /tmp/jpackage_15808073035885342403, 
/media/sf_jds/work/10_sandbox/jdk10/open/test/jdk/tools/jpackage/linux/base/../../apps/image/Hello.java] 
exited with 0 code
TRACE: Execute 
[/home/asemenyu/work/10_sandbox/64/images/jdk/bin/jar]; args(9)=[-c, 
-v, -f, /tmp/jpackage_15808073035885342403/foo.jar, -e, Hello, -C, 
/tmp/jpackage_15808073035885342403, .]...

TRACE: Done. Exit code: 0
TRACE: assertEquals(0): Check command 
[/home/asemenyu/work/10_sandbox/64/images/jdk/bin/jar]; args(9)=[-c, 
-v, -f, /tmp/jpackage_15808073035885342403/foo.jar, -e, Hello, -C, 
/tmp/jpackage_15808073035885342403, .] exited with 0 code
TRACE: Execute 
[/home/asemenyu/work/10_sandbox/64/images/jdk/bin/jpackage]; 
args(14)=[--input, ./input, --output, /home/asemenyu/jpackage_tests, 
--name, ReleaseTest, --package-type, deb, --linux-app-release, Rc3, 
--main-jar, hello.jar, --main-class, Hello]...

TRACE: Done. Exit code: 0
TRACE: assertEquals(0): Check command 
[/home/asemenyu/work/10_sandbox/64/images/jdk/bin/jpackage]; 
args(14)=[--input, ./input, --output, /home/asemenyu/jpackage_tests, 
--name, ReleaseTest, --package-type, deb, --linux-app-release, Rc3, 
--main-jar, hello.jar, --main-class, Hello] exited with 0 code
TRACE: Execute [dpkg]; args(1)=[--print-architecture]; redirect 
output to [/tmp/jpackage_10813571496694787689.out]...

TRACE: Done. Exit code: 0
TRACE: assertEquals(0): Check command [dpkg]; 
args(1)=[--print-architecture] exited with 0 code
TRACE: assertTrue(): Check file 
[/home/asemenyu/jpackage_tests/releasetest_1.0-Rc3_amd64.deb] exists
TRACE: Execute [dpkg-deb]; args(3)=[-f, 
/home/asemenyu/jpackage_tests/releasetest_1.0-Rc3_amd64.deb, 
Version]; redirect output to [/tmp/jpackage_1729501500147798.out]...

TRACE: Done. Exit code: 0
TRACE: assertEquals(0): Check command [dpkg-deb]; args(3)=[-f, 
/home/asemenyu/jpackage_tests/releasetest_1.0-Rc3_amd64.deb, Version] 
exited with 0 code
TRACE: assertTrue(): Check value of Version field [1.0-Rc3] ends with 
Rc3

---

Test output for package installation verification:
---
TRACE: assertTrue(): Check value of jpackage.test.output property 
[/home/asemenyu/jpackage_tests] references a directory
TRACE: assertTrue(): Check value of jpackage.test.output property 
[/home/asemenyu/jpackage_tests] references writable directory

TRACE: Bundler deb supported
TRACE: Execute [dpkg]; args(1)=[--print-architecture]; redirect 
output to [/tmp/jpackage_1127921622487705754.out]...

TRACE: Done. Exit code: 0
TRACE: assertEquals(0): Check command [dpkg]; 
args(1)=[--print-architecture] exited with 0 code
TRACE: Execute [dpkg]; args(2)=[--contents, 
/home/asemenyu/jpackage_tests/releasetest_1.0-Rc3_amd64.deb]; 
redirect output to [/tmp/jpackage_16221854689490241666.out]...

TRACE: Done. Exit code: 0
TRACE: assertEquals(0): Check command [dpkg]; args(2)=[--contents, 
/home/asemenyu/jpackage_tests/releasetest_1.0-Rc3_amd64.deb] exited 
with 0 code
TRACE: assertTrue(): Check application launcher 
[/opt/releasetest/bin/ReleaseTest] is a file
TRACE: assertTrue(): Check application launcher 
[/opt/releasetest/bin/ReleaseTest] can be executed
TRACE: Execute [dpkg]; args(2)=[--contents, 
/home/asemenyu/jpackage_tests/releasetest_1.0-Rc3_amd64.deb]; 
redirect output to [/tmp/jpackage_12615070579893278257.out]...

TRACE: Done. Exit code: 0
TRACE: assertEquals(0): Check command [dpkg

Re: RFR: JDK-8229979: jpackage cleanup src files, help text, and javadoc

2019-08-28 Thread Alexey Semenyuk


Looks good.

Some files in the review contain no diffs though, like 
http://cr.openjdk.java.net/~herrick/8229979/webrev.01/test/jdk/tools/jpackage/windows/exe/WinUpgradeUUIDTest.java.sdiff.html. 
Why are they in the review?


- Alexey

On 8/28/2019 9:36 AM, Andy Herrick wrote:

Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).


[1] https://bugs.openjdk.java.net/browse/JDK-8229979

[2] http://cr.openjdk.java.net/~herrick/8229979/

Thanks,
Andy

Re: RFR: JDK-8229979: jpackage cleanup src files, help text, and javadoc

2019-08-28 Thread Alexey Semenyuk


Understood. Thank you for explanation.

- Alexey

On 8/28/2019 12:43 PM, Andy Herrick wrote:


On 8/28/2019 11:47 AM, Alexey Semenyuk wrote:

Looks good.

Some files in the review contain no diffs though, like 
http://cr.openjdk.java.net/~herrick/8229979/webrev.01/test/jdk/tools/jpackage/windows/exe/WinUpgradeUUIDTest.java.sdiff.html. 
Why are they in the review?


I ran a script to remove extraneous trailing spaces and fix file 
permission.  The result is that the file changed, but webrev has 
nothing to show.  I built the webrev with a file list so all changed 
files are these, even if there is no visible change.


/ANdy



- Alexey

On 8/28/2019 9:36 AM, Andy Herrick wrote:

Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).


[1] https://bugs.openjdk.java.net/browse/JDK-8229979

[2] http://cr.openjdk.java.net/~herrick/8229979/

Thanks,
Andy

Re: RFR: JDK-8230152: No appropriate error message when wix tools missing.

2019-08-29 Thread Alexey Semenyuk


Looks good.

- Alexey

On 8/29/2019 2:18 PM, Andy Herrick wrote:

Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).


[1] https://bugs.openjdk.java.net/browse/JDK-8230152

[2] http://cr.openjdk.java.net/~herrick/8230152/

Thanks

Andy,

Re: WiX customization

2019-08-27 Thread Alexey Semenyuk

The default WiX source file used by jpackage is [1].
WiX variables set by jpackage and referenced from this file have "Jp"
prefix. The meaning of the variables is explained in doc comment of [2]
file. It is also documented what WiX source files are generated by jpackage.

So if you need to customize WiX files generated by jpackage before
jpackage runs WiX compiler, you can do one of the following from your
custom "-post-image.wsf>" script:

1. Replace the default main.wxs with your own file;
2. Edit the default main.wxs produced by jpackage. You can use
powershell scripting for this. See [3]

[1]
http://hg.openjdk.java.net/jdk/sandbox/file/e356758160cd/src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/main.wxs

[2]
http://hg.openjdk.java.net/jdk/sandbox/file/e356758160cd/src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WinMsiBundler.java

[3]
https://superuser.com/questions/592786/powershell-script-to-update-xml-file-content

- Alexey

On 8/27/2019 8:48 AM, Andy Herrick wrote:
We are just beginning to work on user documentation, and
--resource-dir is one area that will need extensive documentation and
examples. (not to mention probably some bug fixes like JDK-8224833
).

basically the proceedure would be as follows:

1.) build your installer first using the --temp-root
and --verbose args.

2.) look for verbose output that says something like:

Using default package resource [] (add
to the resource-dir to customize).

you can look in temp-root-path/config to find all the default
resources it used, and customize them as you require

2.a) there may also be output that something like:

no default package resource [script to run after application image
is populated] (add -post-image.wsf to the resource-dir to
customize).
Then you can add you own -post-image.wsf (though there will
be no default script in temp-root-path/config to customize).

3.) now add --resource-dir option, create
and put in it (or as in 2.a,
"-post-image.wsf>")

4.) now run jpackage again and this time it will take the
custom-resource instead of the default.

/Andy

On 8/27/2019 2:44 AM, Tobias Oelgarte wrote:
I would also be interested in that. At least I would like to know
where I can find the default files used by jpackage and how to
override/modify them if needed.

The current documentation only mentions the --resource-dir option,
but does not provide any detailed information.

Am 26.08.2019 um 20:27 schrieb Tom Vasset (tvasset):

Hi,

I've been experimenting with jpackage for packaging an app with both
a win and a mac installer.

For the windows installer, are there ways to customize the WiX files
produced by jpackage? A simple example is to get rid of the default
red WiX icons in the installer and replace them with product
specific ones (which I would think anyone building an msi would want
to do).

I've tried to find documentation for how to work with the
--resource-dir option (which seems to allow a script to be run), but
I can find no examples of how to use it anywhere...

Regards,

Tom

Re: Comments on jpackage (JEP 343)

2019-09-05 Thread Alexey Semenyuk


Hi Rachel,

Thank you for your feedback. I created 
https://bugs.openjdk.java.net/browse/JDK-8230668 record to track work on 
your suggestions.


- Alexey

On 9/5/2019 8:50 AM, Rachel Greenham wrote:

(Sorry for non-threading, i read the digest)

As you've been lacking feedback from people using the jpackage EA 
builds, here's mine FWIW.


I've been quiet because it's been working well enough for us. That 
said, our needs and process probably simplify matters in that:


1. We're only producing Windows installers
2. We've been lucky in having patient clients during this 
post-webstart, post-javapackager disruption.

3. We were happy to modify our versioning to match Windows standards
4. Our application is non-modular
5. We do it in three steps: jlink to make a JRE, then jpackage to make 
an app image, then jpackage again to make both an exe and msi 
installer based on that image. (client slow to reply which one they'd 
actually prefer!) Not trying to do everything in one step.


Since the fix that made new versions of our app correctly replace 
older ones I've mostly just been testing new EA builds to make sure 
they don't break it! They do sometimes, usually because of changes in 
the parameter names, and of course we lost our Inno Setup 
customisations. I haven't yet made any attempt to customise the EXE 
setup installer since then.


Would be nice:

1. For it to use the supplied app icon for the installer, or be able 
to supply another specifically for the installer. For it to be shown 
in the installer in some fashion. Other exe customisations of 
straightforward branding and/or flags to control what questions 
they're asked would be very nice.
2. For it to be able to sign the installer in the fashion of, or 
actually using, signtool. (Ideally internalised as installing signtool 
itself is a pain.) Currently that's an extra step after the installers 
are built


But I can wait for them, I want it in a release so I can use it via 
ToolProvider rather than execing an external JDK. All the while it's 
the way it is it massively complicates the build.


Later would-be-nices, not for this desktop app, but ability to use it 
to package background service-type apps, as a service for windows, 
using launchd for osx, and systemd for linux.

Re: Comments on jpackage (JEP 343)

2019-09-04 Thread Alexey Semenyuk


Hi Sverre,

Thank you for your feedback.

I've filed [1] bug to address Debian packaging issue.

As for your question regarding release number, it is not supported by 
WiX on Windows. See [2].
Also product version string should follow quite strict rules [3]. 
However you can encode release value in the third component of product 
version (build number) as a workaround on condition release is a number.


[1] https://bugs.openjdk.java.net/browse/JDK-8230612
[2] https://wixtoolset.org/documentation/manual/v3/xsd/wix/product.html
[3] https://docs.microsoft.com/en-us/windows/win32/msi/productversion

- Alexey

On 9/4/2019 5:53 AM, Sverre Moe wrote:

I tired the latest build 14-jpackage+1-35 today. Good to see that debian
package file name is finally up to the specification.

Noticed something though with building the debian package:
When using a control file from the resource directory, jpackage does not
use its version and release.
Must apply "--app-version" and "--linux-app-release" in order to get the
proper version and release on file name.

Running dpkg-deb --show and --info has the correct version and release.
   dpkg-deb --show build/deb/application_1.0-1_amd64.deb
   application 1.1.0-SNAPSHOT20190904113134

I wonder where it gets the version 1.0 from, since my
project.version=1.1.0. The jpackage should at least use the project version
if no other version is specified.

This is a problem only for the debian package on Linux. When building an
RPM, jpackage uses both the Version and Release defined within the spec
resource file.

Isn't release also applicable for Windows and Mac?
What about, instead of calling it "--linux-app-release", why not simply
call it "--app-release". That would stand much better together with
"--app-version".
With "--linux-app-release" it makes it more more verbose when scripting the
build, when it needs to check for Windows and Mac in order to omit that
flag.

/Sverre


tir. 3. sep. 2019 kl. 21:01 skrev :


I spent some time last week playing with the jpackage tool, using build
14-jpackage+1-35 from https://jdk.java.net/jpackage.

Overall, I can see that you’ve made good progress, but there’s still some
work to be done.  I’ll start with high-level comments and questions, and
then comment on my experience using the tool on Debian and then macOS.

High-level comments/questions

   - It’s good that you’re publishing EA builds, but I haven’t seen very
 much feedback from those builds.  It may be better to propose this as
 an experimental feature when it’s ready to target.  That would give
 you the freedom to improve it incompatibly over one or two release
 cycles before you commit to a final version.

   - The tool still generates an image by default, rather than a package.
 This will surprise many users, especially those who just want to do
 something simple and straightforward.  The least-surprising default
 behavior would be to generate a package of the type most suitable for
 the current platform.  An option to generate just an image would be
 fine, for those who want to tweak it before the actual packaging
 step, but that shouldn’t be the default.

   - Related to the previous point, I should only have to specify the
 `--package-type` option if I want something other than the default
 for the current platform.

   - The tool assumes that the application being packaged will have a GUI.
 This isn’t surprising, considering its heritage, but as a consequence
 it always produces packages that perform GUI-specific actions, such
 as installing icons and desktop-menu entries.  If I’m just packaging
 a command-line tool then these are unnecessary, and supporting them
 can pull in lots of additional dependencies (e.g., a ton of Perl
 scripts on Debian).  Consider adding an option (`--gui`?) so that
 the user can indicate when an application is to be installed for
 graphical use.

   - The `--output`/`-o` option is confusing.  It doesn’t name the output
 itself, but rather a directory into which the single item of output
 will be placed.  Typing `-o .` all the time is just annoying.  It’d
 be more logical to rename this option to `--dest`/`-d` and to make it
 optional, with a default value of `.`.

   - If my app is modular, and my main module has a version string, then
 it’d be nice for that to be used as the package version unless a
 specific version is specified on the command line.

   - Terminology: For Linux we generally speak of “packages” rather than
 “bundles.”  Rename `--linux-bundle-name` to `--linux-package-name`.

   - The `--temp-root` option could be shortened to `--temp`.

   - Periods at the ends of error messages are unsightly and unnecessary.
 We don’t use them in other JDK tools.  Please remove them.

   - It’d be nice to have an option that displays the programs being run
 by the tool, in a form that can easily be cut-and-pasted into a
 script for

Re: RFR: JDK-8229779: Shortcut creation policy

2019-09-11 Thread Alexey Semenyuk


SimplePackageTest.java:
I'd suggest to put "Installer should not create any shortcuts" in the 
description or simply remove notice about shortcuts.


Did you omit adding shortcuts to LinuxDebBundler.java on purpose?

- Alexey

On 9/11/2019 9:07 PM, Andy Herrick wrote:

Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).


This fix:

1.) adds the new option --linux-shortcut, and now only creates a 
shortcut on linux if specified


2.) only creates a shortcut on windows if win-menu or win-shortcut is 
specified.


/Andy


[1] https://bugs.openjdk.java.net/browse/JDK-8229779

[2] http://cr.openjdk.java.net/~herrick/8229779

Re: RFR: JDK-8230653: jpackage error on macOS system without xcode

2019-09-12 Thread Alexey Semenyuk


Looks good.

- Alexey

On 9/11/2019 11:46 PM, Alexander Matveev wrote:

Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).


- Error mentioned in bug report was due to missing Xcode when running 
SetFile. Fixed by not running SetFile if Xcode is not available. This 
tool used to set custom icon on DMG file and we do not consider it as 
real error. Verbose output will indicate that custom icon is skipped 
for DMG.
- Signing will fail if Xcode is not installed. Added check for Xcode 
availability if signing is requested. If Xcode is not available and 
signing is specified we will fail with error.


[1] https://bugs.openjdk.java.net/browse/JDK-8230653

[2] http://cr.openjdk.java.net/~almatvee/8230653/webrev.00

Thanks,
Alexander

Re: RFR: JDK-8229779: Shortcut creation policy

2019-09-12 Thread Alexey Semenyuk


Looks good.

Would you mind creating a follow up CR to add jtreg test(s) for the new 
command line option.


- Alexey

On 9/12/2019 7:11 AM, Andy Herrick wrote:

Revised with webrev.03.

Changed SimplePackageTest instructions as suggested and added 
LinuxDebBundler.java to file list (double checked file list used to 
create webrev contains all changed files).


/ANdy

On 9/11/2019 10:09 PM, Alexey Semenyuk wrote:

SimplePackageTest.java:
I'd suggest to put "Installer should not create any shortcuts" in the 
description or simply remove notice about shortcuts.


Did you omit adding shortcuts to LinuxDebBundler.java on purpose?

- Alexey

On 9/11/2019 9:07 PM, Andy Herrick wrote:

Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).


This fix:

1.) adds the new option --linux-shortcut, and now only creates a 
shortcut on linux if specified


2.) only creates a shortcut on windows if win-menu or win-shortcut 
is specified.


/Andy


[1] https://bugs.openjdk.java.net/browse/JDK-8229779

[2] http://cr.openjdk.java.net/~herrick/8229779

Re: RFR: JDK-8230629: jpackage signing on macOS does not work as expected

2019-09-12 Thread Alexey Semenyuk


Looks good, though
---
List args = new ArrayList<>();
 940 args.addAll(Arrays.asList("codesign",
 941 "--verify",
 942 file.toString()));
 943
 944 ProcessBuilder pb
 945 = new ProcessBuilder(args.toArray(new 
String[args.size()]));

---

can be as simple as:
---
ProcessBuilder pb = new ProcessBuilder("codesign", "--verify", 
file.toString());

---

- Alexey

On 9/11/2019 11:53 PM, Alexander Matveev wrote:

Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).


- Binaries in runtime and Frameworks will not be signed directly using 
user provided certificate.
- libapplauncher.dylib will be signed with user provided certificate 
only if it is unsigned.
- When signing is enabled app and pkg will be signed, but not dmg. App 
inside pkg and dmg will be signed as well.


[1] https://bugs.openjdk.java.net/browse/JDK-8230629

[2] http://cr.openjdk.java.net/~almatvee/8230629/webrev.00/

Thanks,
Alexander

Re: RFR: JDK-8230629: jpackage signing on macOS does not work as expected

2019-09-12 Thread Alexey Semenyuk


Thank you, looks good.

- Alexey

On 9/12/2019 5:44 PM, Alexander Matveev wrote:

Hi Alexey,

http://cr.openjdk.java.net/~almatvee/8230629/webrev.01
I simplified isFileSigned() as you suggested.

Thanks,
Alexander

On 9/12/2019 4:13 AM, Alexey Semenyuk wrote:

Looks good, though
---
List args = new ArrayList<>();
 940 args.addAll(Arrays.asList("codesign",
 941 "--verify",
 942 file.toString()));
 943
 944 ProcessBuilder pb
 945 = new ProcessBuilder(args.toArray(new 
String[args.size()]));

---

can be as simple as:
---
ProcessBuilder pb = new ProcessBuilder("codesign", "--verify", 
file.toString());

---

- Alexey

On 9/11/2019 11:53 PM, Alexander Matveev wrote:

Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).


- Binaries in runtime and Frameworks will not be signed directly 
using user provided certificate.
- libapplauncher.dylib will be signed with user provided certificate 
only if it is unsigned.
- When signing is enabled app and pkg will be signed, but not dmg. 
App inside pkg and dmg will be signed as well.


[1] https://bugs.openjdk.java.net/browse/JDK-8230629

[2] http://cr.openjdk.java.net/~almatvee/8230629/webrev.00/

Thanks,
Alexander

RFR: JDK-8230726: Improve jpackage jtreg tests

2019-09-09 Thread Alexey Semenyuk


Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).


- reworked jpackage tests that produce platform specific packages to get 
rid of code duplication;
- replaced install.sh/uninstall.sh scripts on Linux and Windows with 
shared manage_packages.sh script that will batch install/uninstall 
packages. Support for dmg, pkg and exe installers TBD.


[1] https://bugs.openjdk.java.net/browse/JDK-8230726

[2] http://cr.openjdk.java.net/~asemenyuk/8230726/webrev.03

Thanks,
Alexey

Re: RFR: JDK-8230519: jpackage "--package-type" values and default

2019-09-09 Thread Alexey Semenyuk


http://cr.openjdk.java.net/~herrick/8230519/webrev.01/test/jdk/tools/jpackage/share/RuntimeTest.java.sdiff.html:
---
37 "--package-type", "app-image",
38 "--package-type", "app-image",
---
Duplication by accident?

http://cr.openjdk.java.net/~herrick/8230519/webrev.01/src/jdk.jpackage/linux/classes/jdk/jpackage/internal/LinuxDebBundler.java.sdiff.html:
---
// we are just going to run "dpkg -s coreutils" ans assume Debian
---
"ans" - typo? Should it be "and"?

- Alexey

On 9/8/2019 5:50 PM, Andy Herrick wrote:

Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).


This fix:

Adds "app-image" as a valid value for "--package-type" options, 
meaning build an application image instead of a package.


Changes the default value of "--package-type" to a platform dependent 
default package type.


[1] https://bugs.openjdk.java.net/browse/JDK-8230519
[2] http://cr.openjdk.java.net/~herrick/8230519/webrev.01/

Thanks

Andy,

Re: RFR: JDK-8230519: jpackage "--package-type" values and default

2019-09-09 Thread Alexey Semenyuk





On 9/9/2019 1:28 PM, Andy Herrick wrote:


On 9/9/19 1:14 PM, Kevin Rushforth wrote:

Looks good with one question:

In Arguments.java:

+ if (bundler.isDefault()) {
+ return bundler;
+ } else {
+ savedBundler = bundler;
+ }

When would there be a valid case where you loop through the list of 
bundlers and don't find a default? It may be better to throw an error 
in that case rather than just return the last one found.


-- Kevin

This left the possibility that if the default were not supported but 
another form was, then it became the default.


On Windows, the two package types, msi and exe now require the same 
tools, and on linux, deb is only the default if (among other things) 
it is supported.


So that leaves only macOS.  here dmg is default but required hdmiutil 
and osascript.


If either of these are missing dmg is not supported, so this code 
would build pkg package if --package-type not specified.  Would it be 
better to just get error and only build pkg if it is explicitly 
specified as --package-type pkg ?
I think exiting with error if dmg tools are not available on macOS would 
be better. This would be more predictable.


- Alexet



/Andy



On 9/8/2019 2:50 PM, Andy Herrick wrote:

Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).


This fix:

Adds "app-image" as a valid value for "--package-type" options, 
meaning build an application image instead of a package.


Changes the default value of "--package-type" to a platform 
dependent default package type.


[1] https://bugs.openjdk.java.net/browse/JDK-8230519
[2] http://cr.openjdk.java.net/~herrick/8230519/webrev.01/

Thanks

Andy,

Re: RFR: JDK-8230522: rename "--linux-bundle-name", and "--temp-root" options.

2019-09-09 Thread Alexey Semenyuk


Looks good.

- Alexey

On 9/9/2019 3:15 PM, Andy Herrick wrote:

Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).


This fix:

modifies the name of options:

--temp-root, --linux-bundle-name , --mac-bundle-name, 
--mac-bundle-identifier, and --mac-bundle-signing-prefix.


new names:

--temp, --linux-package-name , --mac-package-name, 
--mac-package-identifier, and --mac-package-signing-prefix.


This change also also removes the period at the end of all error 
messages.


[1] https://bugs.openjdk.java.net/browse/JDK-8230522
[2] http://cr.openjdk.java.net/~herrick/8230522

Thanks

Andy,

Re: RFR: JDK-8230920: jpackage problems when -input dir contains any files with "cfg" extension.

2019-09-17 Thread Alexey Semenyuk





On 9/17/2019 3:17 PM, Andy Herrick wrote:

Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).


On Windows  when building MSI, the original application name was 
determined by looking into the /app dir for a ".cfg" file.


The problem was that:

 - There may be application files with ".cfg" extension.

 - There may be multiple ".cfg" files due to --add-launcher option(s)

Instead we create an ".id" in the root of the 
app-image , to insure we can derive application name from app-image.
`.id` will be another well known file. Why it is 
better than `app/.cfg`? Because there can be multiple 
`app/.cfg` files and only a single `name>.id`? What will prevent people from creating their own .id files?
I don't like this solution, to be honest. Its only benefit is that it is 
simple. Can we instead put some data in `app/.cfg` 
file for the main launcher when building app image so that bundle 
packagers can read all .cfg files and find the one that corresponds to 
the main launcher and thus get application name?


- Alexey


[1] https://bugs.openjdk.java.net/browse/JDK-8230920
[2] http://cr.openjdk.java.net/~herrick/8230920


Thanks

Andy,

Re: RFR: JDK-8230654: jpackage package-type dmg on macOS

2019-09-18 Thread Alexey Semenyuk


Looks good.

- Alexey

On 9/17/2019 10:42 PM, Alexander Matveev wrote:

Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).


- Added link to "/Application" folder to DMG for drag and drop app to 
this folder.
- Added background image with arrow pointing from App icon to 
Application folder.
- If adding link and image to DMG fails it will not be considered 
critical error. In headless environment it might not work correctly.

- See JBS issue for screenshot on how DMG will looks like with this fix.

[1] https://bugs.openjdk.java.net/browse/JDK-8230654

[2] http://cr.openjdk.java.net/~almatvee/8230654/webrev.01/

Thanks,
Alexander

RFR: JDK-8225249: LinuxDebBundler and LinuxRpmBundler should share more

2019-09-18 Thread Alexey Semenyuk


Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).


This fix:

- Move common deb and rpm packaging code in the new class 
(jdk.jpackage.internal.LinuxPackageBundler).

- Implement Java runtime packaging on Linux.
- Fix of [3], [4] bugs as a side effect of code refactoring.
- Add shell scripts to run jpackage jtreg tests.
- Add tests for application desktop integration on Linux.
- Add uninstall script to clean leftovers after file associations of the 
app are removed. Uninstalling Linux app with file associations will 
produce the following console output:

---
Running: sudo dpkg -r fileassociationstest
(Reading database ... 250166 files and directories currently installed.)
Removing fileassociationstest (1.0-1) ...
Remove fileassociationstest-FileassociationsTest.desktop default handler 
for application/x-jpackage-jptest1 mime type from 
/usr/share/applications/defaults.list file
Remove fileassociationstest-FileassociationsTest.desktop default handler 
for application/x-jpackage-jptest2 mime type from 
/usr/share/applications/defaults.list file

/usr/share/applications/defaults.list file updated
---
- Clean some unused code.

/Andy


[1] https://bugs.openjdk.java.net/browse/JDK-8225249

[2] http://cr.openjdk.java.net/~asemenyuk/8225249/webrev.02/

[3] https://bugs.openjdk.java.net/browse/JDK-8230899

[4] https://bugs.openjdk.java.net/browse/JDK-8230917

Re: RFR: JDK-8230521: rename --output/-o option and add default value (".")

2019-09-13 Thread Alexey Semenyuk


Looks good.

- Alexey

On 9/13/2019 8:20 PM, Alexander Matveev wrote:

http://cr.openjdk.java.net/~almatvee/8230521/webrev.01/

- Simplified setting default value for destination folder.
- Undo renaming of output variables to dest.
- Modified help messages as per Andy suggestion.
- Removed obsolete tests as per Alexey suggestion.

Thanks,
Alexander

On 9/12/2019 8:16 PM, Alexey Semenyuk wrote:



On 9/12/2019 10:47 PM, Alexey Semenyuk wrote:
http://cr.openjdk.java.net/~almatvee/8230521/webrev.00/src/jdk.jpackage/share/classes/jdk/jpackage/internal/Arguments.java.sdiff.html: 


---
126 Path destPath = Paths.get(".").toAbsolutePath();
 127 if (destPath.getFileName().toString().equals(".")) {
 128 dest = destPath.getParent().toString();
 129 } else {
 130 dest = destPath.toString();
 131 }
---
Are you trying to get rid of trailing "." path component in the 
above code fragment? If yes, then this can be simplified as follows:

---
Path destPath = Paths.get(".").normalize().toAbsolutePath();
---

Or even simpler:
---
Path destPath = Paths.get("").toAbsolutePath();
---

- Alexey


In general I don't like the idea of renaming variables and method 
names from `output` to `dest`. This doesn't add much value to the 
code and is incomplete and thus confusing (e.g.: in all the tests 
OUTPUT variable remains unnamed).

I suggest to change only `--output` to `--dest` tokens in the code.

Slightly unrelated thing. macOS tests
---
test/jdk/tools/jpackage/macosx/base/Base.java
test/jdk/tools/jpackage/macosx/base/FileAssociationsBase.java
test/jdk/tools/jpackage/macosx/base/InstallDirBase.java
test/jdk/tools/jpackage/macosx/base/LicenseBase.java
---
duplicate corresponding shared tests that have been added in the 
patch for https://bugs.openjdk.java.net/browse/JDK-8230726. I didn't 
touch them as I didn't have MAC to try the replacements. Could you 
please just drop these obsolete tests and also run the new tests to 
make sure they work as expected. I mean not just run the tests to 
create package bundles, but also install these bundles and run the 
tests in a mode when they verify packages are properly installed.


- Alexey

On 9/12/2019 9:34 PM, Alexander Matveev wrote:

Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).


- Renamed "--output" to "--dest" and made it optional with default 
to ".".


[1] https://bugs.openjdk.java.net/browse/JDK-8230521

[2] http://cr.openjdk.java.net/~almatvee/8230629/webrev.00/

Thanks,
Alexander

Re: Feedback JEP 343: Packaging Tool

2019-09-11 Thread Alexey Semenyuk


Hi Heiko,

Thank you for giving a try to jpackage and for your feedback!

Please find comments inlined.

On 9/10/2019 4:55 AM, Heiko Wagner wrote:

I am sending this feedback as suggested by the jpackage project
(https://jdk.java.net/jpackage/). I hope this is considered helpful
information.

I have tried the current build "14-jpackage+1-35" on Windows. It pretty
much worked out of the box for me. Here are a few observations I make:

- creating a image of the application is great for building protable
applications. Sometime it is realy great to have the application on a
thumb drive an just run it on any machine; currently i do this manually
via jlink and use launch4j as a native launcher

- MSI installation packages are great when deploying a application into
a controlled it infrastructure, but in turn impose some restictions e.g.
on application updates
Correct. That is why jpackage supports creation of an application image 
not bundled in MSI on Windows to give maximum flexibility.



- my application is currently a portable app and does not use any native
installer like MSI. Automatic updates are handled by the application by
just in place updating the jar files. Deploying the application as a MSI
would require to change the update behaviour. Even if automatic updates
are out of the scope of the current JEP it would be helpful to have a
common solution for this in the long run

- Currently my app has a splash screen, since launch4j has support for a
native splash screen. I have no tried it on jpackage, but the JEP states
that there is no support for native splash screen.

That is correct, jpackage is not offering native splash screen support.

Does this also mean that the functionality of "-splash: fileName" and
its manifest file counter part will not work when using the launcher
generated jpackage?
Right now it is not working as far as I can say from running the simple 
test. This looks like a bug in app launcher generated by jpackage. I've 
filed https://bugs.openjdk.java.net/browse/JDK-8230862 to track this.


- Wher creating a image on Windows pretty much all .DLL from the bin
folder in the runtime are duplicated into the application folder. Is
this intended?
App launcher is linked dynamically with MS run-time libs so we have MS 
run-time dlls in the folder next to the launcher. There is no bold 
reason to keep it this way, we can link app launcher statically with MS 
run-time and get rid of all these dlls.

Created https://bugs.openjdk.java.net/browse/JDK-8230863 to track this.

- Alexey

When using the generic java.exe launcher it is not
required to this. It just works fine with all .DLL/.EXE files in the
runtime bin folder

Thanks for making such a great tool. Keep up the good work.

Regards,

Heiko

Re: RFR: JDK-8230521: rename --output/-o option and add default value (".")

2019-09-12 Thread Alexey Semenyuk





On 9/12/2019 10:47 PM, Alexey Semenyuk wrote:
http://cr.openjdk.java.net/~almatvee/8230521/webrev.00/src/jdk.jpackage/share/classes/jdk/jpackage/internal/Arguments.java.sdiff.html: 


---
126 Path destPath = Paths.get(".").toAbsolutePath();
 127 if (destPath.getFileName().toString().equals(".")) {
 128 dest = destPath.getParent().toString();
 129 } else {
 130 dest = destPath.toString();
 131 }
---
Are you trying to get rid of trailing "." path component in the above 
code fragment? If yes, then this can be simplified as follows:

---
Path destPath = Paths.get(".").normalize().toAbsolutePath();
---

Or even simpler:
---
Path destPath = Paths.get("").toAbsolutePath();
---

- Alexey


In general I don't like the idea of renaming variables and method 
names from `output` to `dest`. This doesn't add much value to the code 
and is incomplete and thus confusing (e.g.: in all the tests OUTPUT 
variable remains unnamed).

I suggest to change only `--output` to `--dest` tokens in the code.

Slightly unrelated thing. macOS tests
---
test/jdk/tools/jpackage/macosx/base/Base.java
test/jdk/tools/jpackage/macosx/base/FileAssociationsBase.java
test/jdk/tools/jpackage/macosx/base/InstallDirBase.java
test/jdk/tools/jpackage/macosx/base/LicenseBase.java
---
duplicate corresponding shared tests that have been added in the patch 
for https://bugs.openjdk.java.net/browse/JDK-8230726. I didn't touch 
them as I didn't have MAC to try the replacements. Could you please 
just drop these obsolete tests and also run the new tests to make sure 
they work as expected. I mean not just run the tests to create package 
bundles, but also install these bundles and run the tests in a mode 
when they verify packages are properly installed.


- Alexey

On 9/12/2019 9:34 PM, Alexander Matveev wrote:

Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).


- Renamed "--output" to "--dest" and made it optional with default to 
".".


[1] https://bugs.openjdk.java.net/browse/JDK-8230521

[2] http://cr.openjdk.java.net/~almatvee/8230629/webrev.00/

Thanks,
Alexander

Re: RFR: JDK-8230521: rename --output/-o option and add default value (".")

2019-09-12 Thread Alexey Semenyuk


http://cr.openjdk.java.net/~almatvee/8230521/webrev.00/src/jdk.jpackage/share/classes/jdk/jpackage/internal/Arguments.java.sdiff.html:
---
126 Path destPath = Paths.get(".").toAbsolutePath();
 127 if (destPath.getFileName().toString().equals(".")) {
 128 dest = destPath.getParent().toString();
 129 } else {
 130 dest = destPath.toString();
 131 }
---
Are you trying to get rid of trailing "." path component in the above 
code fragment? If yes, then this can be simplified as follows:

---
Path destPath = Paths.get(".").normalize().toAbsolutePath();
---

In general I don't like the idea of renaming variables and method names 
from `output` to `dest`. This doesn't add much value to the code and is 
incomplete and thus confusing (e.g.: in all the tests OUTPUT variable 
remains unnamed).

I suggest to change only `--output` to `--dest` tokens in the code.

Slightly unrelated thing. macOS tests
---
test/jdk/tools/jpackage/macosx/base/Base.java
test/jdk/tools/jpackage/macosx/base/FileAssociationsBase.java
test/jdk/tools/jpackage/macosx/base/InstallDirBase.java
test/jdk/tools/jpackage/macosx/base/LicenseBase.java
---
duplicate corresponding shared tests that have been added in the patch 
for https://bugs.openjdk.java.net/browse/JDK-8230726. I didn't touch 
them as I didn't have MAC to try the replacements. Could you please just 
drop these obsolete tests and also run the new tests to make sure they 
work as expected. I mean not just run the tests to create package 
bundles, but also install these bundles and run the tests in a mode when 
they verify packages are properly installed.


- Alexey

On 9/12/2019 9:34 PM, Alexander Matveev wrote:

Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).


- Renamed "--output" to "--dest" and made it optional with default to 
".".


[1] https://bugs.openjdk.java.net/browse/JDK-8230521

[2] http://cr.openjdk.java.net/~almatvee/8230629/webrev.00/

Thanks,
Alexander

Re: RFR: JDK-8228744: file associations broken on linux.

2019-07-30 Thread Alexey Semenyuk


Looks good.

- Alexey

On 7/29/2019 3:19 PM, Andy Herrick wrote:

Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).


[1] https://bugs.openjdk.java.net/browse/JDK-8228744

[2] http://cr.openjdk.java.net/~herrick/8228744/

/Andy

RFR: JDK-8229252 : Add descriptions to Windows jtreg tests

2019-08-07 Thread Alexey Semenyuk


Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).


- Add comments to Windows jtreg tests to help SQE setup their testing.

[1] https://bugs.openjdk.java.net/browse/JDK-8229252

[2] http://cr.openjdk.java.net/~asemenyuk/8229252/webrev.00/

Thanks,
Alexey

RFR: JDK-8215446: JPackageCreateInstallerInstallDirTest fails on OLE7

2019-08-08 Thread Alexey Semenyuk




Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).


- Add all ascending subdirectories of application installation directory 
to the package.


[1] https://bugs.openjdk.java.net/browse/JDK-8215446

[2] http://cr.openjdk.java.net/~asemenyuk/8215446/webrev.00/

Thanks,
Alexey

Re: RFR: JDK-8215446: JPackageCreateInstallerInstallDirTest fails on OLE7

2019-08-08 Thread Alexey Semenyuk





On 8/8/2019 5:35 PM, Alexander Matveev wrote:

Hi Alexey,

Do you know what behavior will be if we have two packages which will 
install into

CompanyName/App1
CompanyName/App2

If App1 is removed will App2 also removed?
No, directory structure of App2 will stay intact. With the suggested fix 
the package will own "/opt" directory if installation directory of the 
package would be "/opt/a/b". I just verified that uninstalling the 
package doesn't affect unrelated contents of "/opt" directory.


- Alexey


Thanks,
Alexander


On 8/8/2019 8:49 AM, Alexey Semenyuk wrote:


Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).


- Add all ascending subdirectories of application installation 
directory to the package.


[1] https://bugs.openjdk.java.net/browse/JDK-8215446

[2] http://cr.openjdk.java.net/~asemenyuk/8215446/webrev.00/

Thanks,
Alexey

RFR: JDK-8229334: JPackager .exe packages cannot be executed due to missing DLL

2019-08-09 Thread Alexey Semenyuk


Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).


- Add build flag to statically link exe wrapper for msi files with MS 
runtime lib.


[1] https://bugs.openjdk.java.net/browse/JDK-8229334

[2] http://cr.openjdk.java.net/~asemenyuk/8229334/webrev.00/

Thanks,
Alexey

Re: RFR: JDK-8224788: jpackage fails on OS X when using --runtime-image

2019-08-08 Thread Alexey Semenyuk


Looks good.

- Alexey

On 8/8/2019 8:31 AM, Andy Herrick wrote:

Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).


JDK-8224788: jpackage fails on OS X when using --runtime-image

[1] https://bugs.openjdk.java.net/browse/JDK-8224788

[2] http://cr.openjdk.java.net/~herrick/8224788/webrev.01/

/Andy

Re: RFR: JDK-8230651: Use version string from main module

2019-09-20 Thread Alexey Semenyuk


Looks good.

Unfortunately the new test helper classes don't support --module option 
yet and the test can not be implemented based on them.


- Alexey

On 9/20/2019 5:54 PM, Alexander Matveev wrote:

Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).


- Version from main module (if exist) will be used as --app-version if 
--app-version is not specified.


[1] https://bugs.openjdk.java.net/browse/JDK-8230651

[2] http://cr.openjdk.java.net/~almatvee/8230651/webrev.01/

Thanks,
Alexander

Re: RFR: JDK-8230649 : Make jpackage tool an experimental feature

2019-09-26 Thread Alexey Semenyuk


Looks good.

- Alexey

On 9/26/2019 6:57 AM, Andy Herrick wrote:
Revised [3] to remove the change to CreateJmods.gmk since it is not 
needed as the module will be resolved because it provides an 
implementation of ToolProvider.


[3] http://cr.openjdk.java.net/~herrick/8230649/webrev.03/

/Andy

On 9/25/2019 10:33 AM, Andy Herrick wrote:

Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).


These are the code changes to make jpackage an experimental feature.

[1] https://bugs.openjdk.java.net/browse/JDK-8230649

[2] http://cr.openjdk.java.net/~herrick/8230649/webrev.02/

/Andy

Re: RFR: JDK-8231279: Change install location for copyright file for Debian package

2019-09-23 Thread Alexey Semenyuk





On 9/23/2019 6:05 PM, Alexander Matveev wrote:

Hi Alexey,

http://cr.openjdk.java.net/~asemenyuk/8231279/webrev.01/src/jdk.jpackage/linux/classes/jdk/jpackage/internal/LinuxDebBundler.java.frames.html 

Maybe add new line between 41-42 and remove 43 to align import static 
with other static imports.
This is how Netbeans manages imports. I don't touch this part of the 
code, just click on "Fix Imports" menu item and magic happens :)


- Alexey


Looks fine.

Thanks,
Alexander

On 9/23/2019 4:49 AM, Alexey Semenyuk wrote:

Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).


Baseline for the fix is [3] patch.

[1] https://bugs.openjdk.java.net/browse/JDK-8231279

[2] http://cr.openjdk.java.net/~asemenyuk/8231279/webrev.01/

[3] http://cr.openjdk.java.net/~asemenyuk/8231277/webrev.00/

Re: RFR: JDK-8230927 : Wrong arguments set for additional launchers

2019-09-24 Thread Alexey Semenyuk


Andy,

Please remove javadoc update about `--linux-deb-copyright-file` option. 
It will be dropped in https://bugs.openjdk.java.net/browse/JDK-8231277 
patch.

Line 180:
---
if (additional.containsKey("java-optiions")) {
---
Looks like a typo. Should be "java-options", not "java-optiions", I guess.
We probably need a test or at least a follow up CR to track the task of 
adding a test for "java-options" parameter in additional launchers.


- Alexey

On 9/24/2019 8:46 AM, Andy Herrick wrote:

Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).


This change applies when arguments or java-options are used in an 
add-launcher properties file.


In these cases the arguments or java-options from the properties files 
should replace instead of being added to the same options used in the 
command line  for the main launcher.


[1] https://bugs.openjdk.java.net/browse/JDK-8230927

[2] http://cr.openjdk.java.net/~herrick/8230927

/Andy

RFR: JDK-8231721: jpackage --install-dir should reject system dirs on Linux

2019-10-01 Thread Alexey Semenyuk


Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).


[1] https://bugs.openjdk.java.net/browse/JDK-8231721

[2] http://cr.openjdk.java.net/~asemenyuk/8231721/webrev.00/

Re: Comments on jpackage (JEP 343)

2019-10-02 Thread Alexey Semenyuk


Hi Sverre,

Thank you for doing this research. I don't think we should complicate 
jpackage by adding signing steps in it.
However we can add a call to custom script after msi is constructed but 
before it get embedded in exe installer.

This script can sign msi.
We already support call of custom script from resource dir before 
building msi. Just need to add another call.


- Alexey

On 10/2/2019 9:41 AM, Sverre Moe wrote:

ons. 25. sep. 2019 kl. 15:45 skrev Sverre Moe :


I have some new comments regarding the Windows build of jpackage.

1)
Is there any way to build an trusted application installer using WiX?
I want to avoid "Unknown Publisher" when installing the application.
Also having problems with Windows Defender SmartScreen, depending on what
settings the user has (Block, Warn, Off).
If Block, the user cannot install the application. If Warn, the user can
click "More info", then "Run anyway".




I have looked into this. It can be done with using tools like insignia [1]
and signtool [2].

It can be done after the MSI has been built by jpackage using the tool
SignTool from the Microsoft SDK.
I successfully managed to sign the MSI and EXE built by jpackage:

$ /cygdrive/c/Program\ Files\ \(x86\)/Windows\

Kits/10/bin/10.0.18362.0/x64/signtool.exe sign /v /a /d "Application
Installer" /f "cert.pfx" /p certpass /fd SHA256 /t
http://timestamp.digicert.com build/native/application-1.1.0.msi

It could also be beneficial to sign the application executable in the
application image prior to creating the application installer package.
Since the native application executable does not have write access after
being constructed by jpackage, then in order to use signtool on it I had to
modify the file permissions.

I have yet to find out how to do it with WiX.

[1] https://wixtoolset.org/documentation/manual/v3/overview/insignia.html
[2] https://docs.microsoft.com/en-us/windows/win32/seccrypto/signtool

/Sverre

1 2 3 4 5 6 7 >

1 - 100 of 631 matches

Mail list logo