Re: RFR: JDK-8228744: file associations broken on linux.
Looks good. -- Kevin On 7/29/2019 12: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-8228744: file associations broken on linux.
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
Re: jpackage: packaging a real application
Thanks for the heads up on linux file associations. I have filed JDK-8228744 and make sure it is fixed. As to the customization of the msi scripts, it is generally the intention of the implementation that all resources would be fetched by calling fetchResource() in AbstractBundler.java. I can see from the current implementation that only the post install script (for which there is no default resource) is fetched in this way (all others, including main.wxs, just calling getResourceAsStream() which will only get the default resources). If the code were to call fetchResource() (as intended) instead of getResourceAsStream(), you would have the capability to use option "--resource-dir " with pointing to a directory containing any resource you want to override. I will investigate this further and get back to you. /Andy On 7/27/2019 2:30 AM, Nicolas Roduit wrote: Hi all, I'm trying to use jpackage to replace deployment by Java Web Start. I have set up a continuous build to allow the construction of a package on Windows, Mac and Linux. The latest changes to the directory change of the launch binaries and the change in the value of the current working directory required a series of modification in my build. However, there is a bug on Linux for the installation of the file association, see the proposed patch in attachment. There is another problem that seems to me to be major. It is to no longer possible to overload the construction of the MSI. I modified the code to be able to add my own main.wxs file. I think that being able to fully overload main.wxs is essential even if many users will just use the default template. Best, Nicolas
[Ping] RFR: 8176894 Provide specialized implementation for default methods putIfAbsent, computeIfAbsent, computeIfPresent, compute, merge in TreeMap
Hello everybody! A gentle reminder: please review the changeset and the CSR. Thanks! With best regards, Tagir Valeev On Mon, Jul 15, 2019 at 5:58 PM Tagir Valeev wrote: > Hello! > > Please review the following patch: > http://cr.openjdk.java.net/~tvaleev/webrev/8176894/r2/ > https://bugs.openjdk.java.net/browse/JDK-8176894 > > Also please review the associated CSR: > https://bugs.openjdk.java.net/browse/JDK-8227666 > > The patch was originally submitted by Sergey Kuksenko in March 2017 and > reviewed by some people: > http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-March/046825.html > The latest patch submitted by Sergey is here: > http://cr.openjdk.java.net/~skuksenko/corelibs/utils/8176894/webrev.01/ > > I asked Sergey why it was abandoned. Seems there were no particular reason > and Sergey asked if I could pick up this work. I will be happy to finish it. > > Here's the list of differences between the latest Sergey patch and my > patch: > - A bug is fixed in putIfAbsent implementation. TreeMap.java, lines 576 > and 596: `|| oldValue == null` condition added (the null value should be > overwritten no matter what) > - A testcase is added to cover this problem (InPlaceOpsCollisions.java, > also checks HashMap and LinkedHashMap). Not sure if it's the best place for > such test though. Probably a separate file would be better? > - TreeMap.merge() implementation is added. > - TreeMap is added to the FunctionalCMEs.java test (btw this file > copyright says that it's a subject to Classpath exception which is probably > wrong?) > - Simple microbenchmark is added: TreeMapUpdate.java > > My quick benchmarking shows that optimized version is indeed faster for > the most of the tests and no regression is observed for put() method. > Here's raw results of jdk13-ea+26 and jdk13-ea+26+patch if anybody is > interested. > http://cr.openjdk.java.net/~tvaleev/jmh/JDK-8176894/ > > With best regards, > Tagir Valeev. >
jpackage: packaging a real application
Hi all,
I'm trying to use jpackage to replace deployment by Java Web Start. I
have set up a continuous build to allow the construction of a package on
Windows, Mac and Linux.
The latest changes to the directory change of the launch binaries and
the change in the value of the current working directory required a
series of modification in my build. However, there is a bug on Linux for
the installation of the file association, see the proposed patch in
attachment.
There is another problem that seems to me to be major. It is to no
longer possible to overload the construction of the MSI. I modified the
code to be able to add my own main.wxs file. I think that being able to
fully overload main.wxs is essential even if many users will just use
the default template.
Best,
Nicolas
diff --git a/src/jdk.jpackage/linux/classes/jdk/jpackage/internal/LinuxDebBundler.java b/src/jdk.jpackage/linux/classes/jdk/jpackage/internal/LinuxDebBundler.java
index 0feefa1d5..6e99fa920 100644
--- a/src/jdk.jpackage/linux/classes/jdk/jpackage/internal/LinuxDebBundler.java
+++ b/src/jdk.jpackage/linux/classes/jdk/jpackage/internal/LinuxDebBundler.java
@@ -546,7 +546,7 @@ private boolean prepareProjectConfig(Map params)
.append(LINUX_INSTALL_DIR.fetchFrom(params))
.append("/")
.append(data.get("APPLICATION_FS_NAME"))
-.append("/")
+.append("/bin/")
.append(mimeInfoFile)
.append("\n");
@@ -554,7 +554,7 @@ private boolean prepareProjectConfig(Map params)
.append(LINUX_INSTALL_DIR.fetchFrom(params))
.append("/")
.append(data.get("APPLICATION_FS_NAME"))
-.append("/")
+.append("/bin/")
.append(mimeInfoFile)
.append("\n");
addedEntry = true;
diff --git a/src/jdk.jpackage/linux/classes/jdk/jpackage/internal/LinuxRpmBundler.java b/src/jdk.jpackage/linux/classes/jdk/jpackage/internal/LinuxRpmBundler.java
index 8a9daf550..8445679c6 100644
--- a/src/jdk.jpackage/linux/classes/jdk/jpackage/internal/LinuxRpmBundler.java
+++ b/src/jdk.jpackage/linux/classes/jdk/jpackage/internal/LinuxRpmBundler.java
@@ -460,7 +460,7 @@ private boolean prepareProjectConfig(Map params)
.append(LINUX_INSTALL_DIR.fetchFrom(params))
.append("/")
.append(data.get("APPLICATION_FS_NAME"))
-.append("/")
+.append("/bin/")
.append(mimeInfoFile)
.append("\n");
@@ -468,7 +468,7 @@ private boolean prepareProjectConfig(Map params)
.append(LINUX_INSTALL_DIR.fetchFrom(params))
.append("/")
.append(data.get("APPLICATION_FS_NAME"))
-.append("/")
+.append("/bin/")
.append(mimeInfoFile)
.append("\n");
addedEntry = true;
Re: [14] RFR: 8212970: TZ database in "vanguard" format support
Hi Naoto, Thanks for the explanation. Looks good. Roger On 7/25/19 4:04 PM, naoto.s...@oracle.com wrote: Hi Roger, On 7/25/19 7:47 AM, Roger Riggs wrote: Hi Naoto, TestZoneInfo310.java: With the composition of the tzdir path up and over to the make directory for the tzdir it might be useful to do an explicit check that the directory exists. That way if the directory structure on the build side changes, there will be a test failure makine it obvious that the dependency has changed. If the input tz data files, either in "test" tree or "make" tree, cannot be located, the test will fail which effectively reports if there is a repo structure change. So I believe it is ok as it is. Aside from it, the latest changes to eliminate the duplicates caused that regression test fail. The reason was that there were actually two "jdk11_backward" data files each in "tzdata" and "tzdata_jdk" test directories, and the contents differ! I am not sure the reason why there are two files this way (seems to be so for years), so I reverted that exact file as before. Here is the webrev reflected that: http://cr.openjdk.java.net/~naoto/8212970/webrev.12/ Naoto Looks fine. Thanks, Roger On 7/24/19 6:24 PM, naoto.s...@oracle.com wrote: Hi Joe, Thank you for the review. On 7/24/19 2:57 PM, Joe Wang wrote: Hi Naoto, The method findNegativeSavings method in TzdbZoneRulesProvider.java states that it "Find the minimum negative savings". While the result is correct since the rules all have the same value for SAVE, I wonder if that's ideal conceptually. Given a start LDT, shouldn't it be looking for the SAVE in the exact (narrower) date range (e.g. 1981 - 1989 vs 1981 - max)?. I believe it is working as such. The end year is retrieved within the method (line 879) and only the minimum negative saving values within the window is filtered. NegativeDSTTest verifies the tzdata, that is the adjusted data after import, is that correct? I wonder a comment and a bit of details in the test summary would be helpful since there is no negative data in the test itself. Good point. It is confusing. I supplied summary text in the test (also the similar line in TestZoneRules.java) Here is the updated webrev: http://cr.openjdk.java.net/~naoto/8212970/webrev.11/ Naoto Best, Joe On 7/23/19 3:15 PM, naoto.s...@oracle.com wrote: Hi, Please review the fix to the following enhancement: https://bugs.openjdk.java.net/browse/JDK-8212970 The proposed changeset is located at: https://cr.openjdk.java.net/~naoto/8212970/webrev.09/ This change aims to support the "vanguard" IANA time zone data format, which uses the negative savings and transition time beyond a day period. The change basically translates those negative savings and transition times, such as 25:00, into the ones that the current JDK recognizes, then produces the data file "tzdb.dat" at the build time. At the run time, the data file is read and interpreted as before. This way the produced tzdb.dat is compatible with the prior JDK releases so that the TZ Updater can also distribute it as a time zone update. I have also refactored redundant copy of ZoneRules file in the build directory, by dynamically importing the file under src. Thus some build related files are modified. I am hoping folks on the build-dev can review those changes. Naoto
Re: RFR (XXS): 8228722: jpackage RPM tests fail on some versions of rpmbuild
looks good. /Andy On 7/29/2019 10:43 AM, Dmitry Chuyko wrote: Hello, Please review a tiny fix of a test bug that appears in some environments. While extending jpackage platforms support in JDK-8222778 I used "-E" rpmbuild shortcut for arch detection. It seems to be missing in some versions while full "--eval" flag name is more generic. bug: https://bugs.openjdk.java.net/browse/JDK-8228722 webrev: http://cr.openjdk.java.net/~dchuyko/8228722/webrev.00/ testing: jpackage jtreg tests on x86_64, aarch64 and other archs, Ubuntu 16.04. Webrev is made for 'JDK-8200758-branch' branch of open 'sandbox' repo. -Dmitry
RFR (XXS): 8228722: jpackage RPM tests fail on some versions of rpmbuild
Hello, Please review a tiny fix of a test bug that appears in some environments. While extending jpackage platforms support in JDK-8222778 I used "-E" rpmbuild shortcut for arch detection. It seems to be missing in some versions while full "--eval" flag name is more generic. bug: https://bugs.openjdk.java.net/browse/JDK-8228722 webrev: http://cr.openjdk.java.net/~dchuyko/8228722/webrev.00/ testing: jpackage jtreg tests on x86_64, aarch64 and other archs, Ubuntu 16.04. Webrev is made for 'JDK-8200758-branch' branch of open 'sandbox' repo. -Dmitry
Re: [14] RFR: 8212970: TZ database in "vanguard" format support
Thanks for these changes, +1 Stephen On Tue, 23 Jul 2019 at 23:18, wrote: > > Hi, > > Please review the fix to the following enhancement: > > https://bugs.openjdk.java.net/browse/JDK-8212970 > > The proposed changeset is located at: > > https://cr.openjdk.java.net/~naoto/8212970/webrev.09/ > > This change aims to support the "vanguard" IANA time zone data format, > which uses the negative savings and transition time beyond a day period. > The change basically translates those negative savings and transition > times, such as 25:00, into the ones that the current JDK recognizes, > then produces the data file "tzdb.dat" at the build time. At the run > time, the data file is read and interpreted as before. This way the > produced tzdb.dat is compatible with the prior JDK releases so that the > TZ Updater can also distribute it as a time zone update. > > I have also refactored redundant copy of ZoneRules file in the build > directory, by dynamically importing the file under src. Thus some build > related files are modified. I am hoping folks on the build-dev can > review those changes. > > Naoto
