Fix test failures. They didn't fail in Mach5 test runs as WiX was not available
on test machines and these tests were not executed.
-
Commit messages:
- 8227400: Adjust jib profiles to make 3rd party tools for creating installers
available on Mach5 test machines
Changes:
On Mon, 16 Nov 2020 15:15:02 GMT, Andy Herrick wrote:
> … fix linux DTI
Changes requested by asemenyuk (Committer).
test/jdk/tools/jpackage/helpers/jdk/jpackage/test/JPackageCommand.java line 484:
> 482: return TKit.getCurrentDefaultAppName();
> 483: }
> 484:
I don't like the
On Mon, 16 Nov 2020 19:01:57 GMT, Alexey Semenyuk wrote:
>> … fix linux DTI
>
> Changes requested by asemenyuk (Committer).
In these two scenarios what would be the name of the installer:
1. phase 1: --name Foo; phase 2: --name Bar --app-image
2. phase 1: --name Foo; phase 2: --ap
On Fri, 30 Oct 2020 12:47:08 GMT, Andy Herrick wrote:
>> JVM
>
> Andy Herrick has updated the pull request incrementally with one additional
> commit since the last revision:
>
> JDK-8254920: Application launched with jpackage produced .exe crashes JVM
Marked as reviewed by asemenyuk
On Sat, 17 Oct 2020 14:01:22 GMT, Andy Herrick wrote:
> …from installer name
> JDK-8254783: jpackage fails on Windows when application name differs from
> installer name
> When using --app-image, to create MSI installer, use the application name
> from AppImageData instead of the Msi
>
Don't run ldd and build list of dependency packages in case jpackage builds DEB
package on non Debian Linux and RPM on Debian Linux. In this cases attempts to
detect what packages provide libs will fail anyways, so don't waste time and
pollute jpackage log output.
-
Commit
t 28, 2020 at 8:59 PM Alexey Semenyuk
mailto:alexey.semen...@oracle.com>> wrote:
Daniel,
https://bugs.openjdk.java.net/browse/JDK-8240111 has been updated
with the evaluation of your request. Please take a look.
- Alexey
On 2/27/2020 2:00 AM, Daniel Peintner wrote:
On Thu, 29 Oct 2020 17:32:24 GMT, Andy Herrick wrote:
> JVM
test/jdk/tools/jpackage/helpers/jdk/jpackage/test/HelloApp.java line 276:
> 274: AppOutputVerifier av = getVerifier(cmd, args);
> 275: if (av != null) {
> 276: // when running app launchers, clear users
to actually start the application nothing happens. It
silently fails.
Could this be a reason why you don't encounter any issue? Just an idea
though...
-- Daniel
Alexey Semenyuk <mailto:alexey.semen...@oracle.com>> schrieb am Mi., 26. Feb. 2020, 22:56:
Daniel,
Interesting. We h
822: Need to create exploded tests covering all forms of modules
-
Commit messages:
- 822: Need to create exploded tests covering all forms of modules
- 822: Need to create exploded tests covering all forms of modules
Changes:
On Thu, 7 Jan 2021 16:40:26 GMT, Andy Herrick wrote:
> JDK-8259238: Clean up Log.java and remove usage of non-final static variables.
Marked as reviewed by asemenyuk (Committer).
-
PR: https://git.openjdk.java.net/jdk/pull/1977
On Mon, 11 Jan 2021 17:42:21 GMT, Andy Herrick wrote:
> JDK-8258755: jpackage: Invalid 32-bit exe when building app-image
Changes requested by asemenyuk (Committer).
src/jdk.jpackage/share/native/applauncher/JvmLauncher.h line 37:
> 35: #define LAUNCH_FUNC "JLI_Launch"
> 36: #endif
> 37:
On Wed, 13 Jan 2021 01:32:51 GMT, Alexey Semenyuk wrote:
>> JDK-8258755: jpackage: Invalid 32-bit exe when building app-image
>
> src/jdk.jpackage/share/classes/jdk/jpackage/internal/Platform.java line 127:
>
>> 125: return is64b;
>> 126: }
>> 12
On Wed, 6 Jan 2021 15:52:07 GMT, Andy Herrick wrote:
> JDK-8259062: Remove MacAppStoreBundler
Marked as reviewed by asemenyuk (Committer).
-
PR: https://git.openjdk.java.net/jdk/pull/1962
On Wed, 13 Jan 2021 13:14:17 GMT, Andy Herrick wrote:
>> I agree is better to have the check in windows specific code (not Platform)
>> and will move it.
>> The "os.arch" System property in 32 java is "x86" regardless of whether
>> running on 64 or 32 bit version of Windows, It reflects the
On Mon, 11 Jan 2021 17:42:21 GMT, Andy Herrick wrote:
> JDK-8258755: jpackage: Invalid 32-bit exe when building app-image
Marked as reviewed by asemenyuk (Committer).
-
PR: https://git.openjdk.java.net/jdk/pull/2030
On Fri, 29 Jan 2021 22:00:32 GMT, Phil Race wrote:
>> Fix for https://bugs.openjdk.java.net/browse/JDK-8254702
>>
>> The fix splits Linux app launcher in app launcher and launcher shared lib.
>> App launcher is pure C and doesn't have C++ code. App launcher lib
>> incorporates bulk of C++
launcher code on other
> platforms.
> - `applaunchercommon`: code shared between launcher and launcher lib on Linux
> and launcher code on other platforms.
Alexey Semenyuk has refreshed the contents of this pull request, and previous
commits have been removed. The incremental views
On Thu, 28 Jan 2021 14:33:35 GMT, Aleksey Shipilev wrote:
> If you run x86 configuration (cross-compiled on x86_64), then many tests
> would fail with:
>
> $ CONF=linux-x86-server-fastdebug make images run-test TEST=tools/jpackage
> ...
> can not load libgnomevfs-2.so
> Exception in thread
On Mon, 1 Feb 2021 12:16:09 GMT, Magnus Ihse Bursie wrote:
>> Alexey Semenyuk has refreshed the contents of this pull request, and
>> previous commits have been removed. The incremental views will show
>> differences compared to the previous content of the PR. The pull reques
On Mon, 1 Feb 2021 12:19:56 GMT, Magnus Ihse Bursie wrote:
>> Alexey Semenyuk has refreshed the contents of this pull request, and
>> previous commits have been removed. The incremental views will show
>> differences compared to the previous content of the PR. The pull reques
launcher code on other
> platforms.
> - `applaunchercommon`: code shared between launcher and launcher lib on Linux
> and launcher code on other platforms.
Alexey Semenyuk has updated the pull request incrementally with one additional
commit since the last revision:
8254702: jpac
On Wed, 3 Feb 2021 14:08:13 GMT, Andy Herrick wrote:
> Remove lines in WixSourceBuilder that adds directive to rm-rf the parent
> dir(s) of the install-dir. These directories get removed anyway if they are
> empty without these lines, and should be left alone if not empty after
> removing
On Mon, 1 Feb 2021 23:41:38 GMT, Alexander Matveev wrote:
> We did not able to run "hdiutil convert" due to hdiutil did not able to
> acquire lock on DMG image file. In this condition we got "Resource busy" from
> "hdiutil detach" and on repeated attempt we was getting "File Not Found"
>
On Thu, 28 Jan 2021 22:05:17 GMT, Aleksey Shipilev wrote:
>> test/jdk/tools/jpackage/apps/image/Hello.java line 166:
>>
>>> 164: }
>>> 165:
>>> 166: if (!Desktop.isDesktopSupported()) {
>>
>> Would it make more sense to replace
>> `if (GraphicsEnvironment.isHeadless())`
>>
On Tue, 2 Feb 2021 03:59:00 GMT, Alexander Matveev wrote:
>> We did not able to run "hdiutil convert" due to hdiutil did not able to
>> acquire lock on DMG image file. In this condition we got "Resource busy"
>> from "hdiutil detach" and on repeated attempt we was getting "File Not
>> Found"
On Wed, 27 Jan 2021 12:43:40 GMT, Andy Herrick wrote:
> Fixing FileUtils.dirname() to skip over "/.".
Changes requested by asemenyuk (Committer).
src/jdk.jpackage/share/native/common/FileUtils.cpp line 57:
> 55: tstring dirname(const tstring ) {
> 56: tstring::size_type pos;
> 57: if
Hi Maurizio,
This is not known issue.
Can you run the app with "JPACKAGE_DEBUG" env variable set to "true". In
this case the app launcher will produce debug output that will help to
understand why it can't find libjava.so.
- Alexey
On 6/16/2021 9:11 AM, Maurizio Cimadamore wrote:
Hi,
I'm
.Main]
Error: could not find libjava.so
Error: Could not find Java SE Runtime Environment.
```
Does that clarify things?
Thanks
Maurizio
On 16/06/2021 18:28, Alexey Semenyuk wrote:
Hi Maurizio,
This is not known issue.
Can you run the app with "JPACKAGE_DEBUG" env variable set to &q
…ages
-
Commit messages:
- 8264144: Add handling of "--about-url" CLI parameter for RPM/DEB packages
Changes: https://git.openjdk.java.net/jdk/pull/4415/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk=4415=00
Issue: https://bugs.openjdk.java.net/browse/JDK-8264144
> …ages
Alexey Semenyuk has updated the pull request with a new target base due to a
merge or a rebase. The incremental webrev excludes the unrelated changes
brought in by the merge/rebase. The pull request contains two additional
commits since the last revision:
- Merge branch 'mas
On Tue, 8 Jun 2021 16:45:27 GMT, Alexey Semenyuk wrote:
> …ages
This pull request has now been integrated.
Changeset: bcaa2cb1
Author: Alexey Semenyuk
URL:
https://git.openjdk.java.net/jdk/commit/bcaa2cb154ae5d23a067f6e38a19a21eef8fe8e8
Stats: 115 lines in 5 files changed:
Thanks. I'll look into it.
- Alexey
On 6/17/2021 2:01 PM, Maurizio Cimadamore wrote:
Filed this:
https://bugs.openjdk.java.net/browse/JDK-8268974
Maurizio
On 17/06/2021 18:52, Alexey Semenyuk wrote:
Seems like a new issue. Please file a bug in Jira.
- Alexey
On 6/16/2021 5:14 PM
Maurizio
On 16/06/2021 22:11, Maurizio Cimadamore wrote:
Hi,
I've built my JDK this morning. I checked now with `git log` and I do
have:
https://bugs.openjdk.java.net/browse/JDK-8267598
Maurizio
On 16/06/2021 21:12, Alexey Semenyuk wrote:
Hi Maurizio,
Thank you for the provided output.
On Tue, 22 Jun 2021 21:59:43 GMT, Alexander Matveev
wrote:
> Looks like another "Resource busy" issue similar to recent fixes for "hdiutil
> convert" and "hdiutil detach". Workaround in same way by repeating "create"
> command. Modified RetryExecutor to pass write to file flag, otherwise
>
looks for "/lib/". But this is wrong order as it should
> look for "/lib/" first. I.e. TruncatePath() should look for "/bin/" and then
> for "/lib/" if called from GetApplicationHome() and for "/lib/" first and
> then for "/bin/" i
On Fri, 18 Jun 2021 22:46:24 GMT, Alexey Semenyuk wrote:
> GetApplicationHomeFromDll() fails if the path to libjli.so contains "bin"
> component (/tmp/bin/HelloWorld/lib/runtime/lib/libjli.so). TruncatePath()
> looks for "/bin/" first in "/tmp/bin/He
On Mon, 21 Jun 2021 20:21:58 GMT, Andy Herrick wrote:
> …t.java failed "AssertionError: Failed: Check icon"
Changes requested by asemenyuk (Reviewer).
test/jdk/tools/jpackage/windows/WinInstallerIconTest.java line 75:
> 73:
> 74: // Create another installer with custom icon.
> 75:
On Tue, 22 Jun 2021 12:34:04 GMT, Andy Herrick wrote:
>> …t.java failed "AssertionError: Failed: Check icon"
>
> Andy Herrick has updated the pull request incrementally with one additional
> commit since the last revision:
>
> JDK-8268404: [TESTBUG]
GetApplicationHomeFromDll() fails if the path to libjli.so contains "bin"
component (/tmp/bin/HelloWorld/lib/runtime/lib/libjli.so). TruncatePath() looks
for "/bin/" first in "/tmp/bin/HelloWorld/lib/runtime/lib/libjli.so" string and
then it looks for "/lib/". But this is wrong order as it
On Tue, 8 Jun 2021 14:06:50 GMT, Andy Herrick wrote:
>> JDK-8267764: jpackage cannot handle window screensaver files when EXE
>> renamed as SCR
>
> Andy Herrick has updated the pull request with a new target base due to a
> merge or a rebase. The incremental webrev excludes the unrelated
On Wed, 12 May 2021 20:34:08 GMT, Alexey Semenyuk wrote:
> 8266162: Remove JPackage duplicate tests
This pull request has now been integrated.
Changeset: f3c6cda4
Author: Alexey Semenyuk
URL:
https://git.openjdk.java.net/jdk/commit/f3c6cda47631cc123dbcddbfb627dc05cf7bc13b
St
On Fri, 7 May 2021 23:07:02 GMT, Alexander Matveev wrote:
>> test/jdk/tools/jpackage/helpers/jdk/jpackage/test/Functional.java line 161:
>>
>>> 159: }
>>> 160:
>>> 161: if
>>> (throwable.getClass().getName().equals("jtreg.SkippedException")) {
>>
>> Would it make sense to
On Sat, 8 May 2021 01:44:46 GMT, Alexander Matveev wrote:
>> - Replaced direct TKit.run() calls with Test annotation.
>> - Increased timeout for SigningPackageTest from default to 360 due to
>> timeout. This is regression from JDK-8248904 due to changes done in signing
>> and
On Fri, 7 May 2021 02:48:44 GMT, Alexander Matveev wrote:
> - Replaced direct TKit.run() calls with Test annotation.
> - Increased timeout for SigningPackageTest from default to 360 due to
> timeout. This is regression from JDK-8248904 due to changes done in signing
> and --remove-signature
installation directory of Java runtime. However when installing Java runtime
> or app in /usr tree, copyright file will be placed outside of installation
> directory. Thus copyright file should be always created if package
> installation directory is inside of /usr tree.
Alexey Semenyu
jpackage should create copyright file in /usr/share/doc directory tree when
building .deb package for Java runtime with installation directory in /usr
directory tree.
jpackage creates share/doc/copyright file in installation directory for apps
installed outside of /usr tree.
jpackage creates
On Tue, 11 May 2021 03:40:19 GMT, Alexander Matveev
wrote:
>> - Replaced direct TKit.run() calls with Test annotation.
>> - Increased timeout for SigningPackageTest from default to 360 due to
>> timeout. This is regression from JDK-8248904 due to changes done in signing
>> and
8266162: Remove JPackage duplicate tests
-
Commit messages:
- 8266162: Remove JPackage duplicate tests
Changes: https://git.openjdk.java.net/jdk/pull/4003/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk=4003=00
Issue: https://bugs.openjdk.java.net/browse/JDK-8266162
On Thu, 20 May 2021 22:25:10 GMT, Alexander Matveev
wrote:
>> For debug build on macOS, runtime which used for test fill be located in
>> /path/jdk-17/fastdebug and /path/jdk-17 will not contain any other files
>> except fastdebug and in this case our check to decide if we need to copy app
On Fri, 14 May 2021 04:24:42 GMT, Alexander Matveev
wrote:
> Looks like it is similar to JDK-8236282, except for "hdiutil create". Based
> on call stack from failed test we launched "hdiutil create" and were waiting
> for it to terminate while reading output from it. However, based on process
On Thu, 6 May 2021 01:22:41 GMT, Alexey Semenyuk wrote:
> jpackage should create copyright file in /usr/share/doc directory tree when
> building .deb package for Java runtime with installation directory in /usr
> directory tree.
>
> jpackage creates share/doc/copyright file
On Wed, 19 May 2021 21:00:07 GMT, Alexander Matveev
wrote:
> For debug build on macOS, runtime which used for test fill be located in
> /path/jdk-17/fastdebug and /path/jdk-17 will not contain any other files
> except fastdebug and in this case our check to decide if we need to copy app
> or
On Fri, 21 May 2021 04:34:22 GMT, Alexander Matveev
wrote:
> Looks like another issue similar to hdiutil (JDK-8249395) when process is
> gone, but we still waiting for it. I was not able to reproduce this issue by
> running test or pkgbuild separately and conclusion was made based on logs.
>
On Wed, 2 Jun 2021 13:48:47 GMT, Andy Herrick wrote:
> JDK-8267764: jpackage cannot handle window screensaver files when EXE renamed
> as SCR
Marked as reviewed by asemenyuk (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/4306
On Thu, 3 Jun 2021 16:07:13 GMT, Andy Herrick wrote:
>> JDK-8267598: jpackage removes system libraries from java.library.path
>
> Andy Herrick has updated the pull request with a new target base due to a
> merge or a rebase. The incremental webrev excludes the unrelated changes
> brought in by
On Fri, 21 May 2021 12:22:16 GMT, Andy Herrick wrote:
> JDK-8267423: Fix copyrights in jpackage tests
Marked as reviewed by asemenyuk (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/4144
On Sat, 3 Jul 2021 07:41:40 GMT, Alan Bateman wrote:
>> Is it possible to add a test for this that is completely independent of
>> jpackage? I think there are a few existing tests that copy the run-time
>> image to a new location for testing purposes.
>>
>> We may need to rename the JBS
looks for "/lib/". But this is wrong order as it should
> look for "/lib/" first. I.e. TruncatePath() should look for "/bin/" and then
> for "/lib/" if called from GetApplicationHome() and for "/lib/" first and
> then for "/bin/" i
On Fri, 2 Jul 2021 22:17:09 GMT, Alexey Semenyuk wrote:
> Disable stripping to prevent rpmbuild from modifying executables
This pull request has now been integrated.
Changeset: 6000950b
Author: Alexey Semenyuk
URL:
https://git.openjdk.java.net/jdk17/com
looks for "/lib/". But this is wrong order as it should
> look for "/lib/" first. I.e. TruncatePath() should look for "/bin/" and then
> for "/lib/" if called from GetApplicationHome() and for "/lib/" first and
> then for "/bin/" i
Disable stripping to prevent rpmbuild from modifying executables
-
Commit messages:
- Disable executables stripping
Changes: https://git.openjdk.java.net/jdk17/pull/207/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk17=207=00
Issue:
On Sun, 20 Jun 2021 07:25:54 GMT, Alan Bateman wrote:
>> GetApplicationHomeFromDll() fails if the path to libjli.so contains "bin"
>> component (/tmp/bin/HelloWorld/lib/runtime/lib/libjli.so). TruncatePath()
>> looks for "/bin/" first in "/tmp/bin/HelloWorld/lib/runtime/lib/libjli.so"
>>
jpackage app launcher randomly crashes JVM at termination in EMS enabled JDK
builds.
Until the root cause of the issue is understood and fixed let's add a
workaround to jpackage tests to run test app few more times if the first
attempt resulted in app crash.
-
Commit messages:
-
On Fri, 25 Jun 2021 22:41:10 GMT, Alexey Semenyuk wrote:
> jpackage app launcher randomly crashes JVM at termination in EMS enabled JDK
> builds.
> Until the root cause of the issue is understood and fixed let's add a
> workaround to jpackage tests to run test app few more times
On Thu, 8 Jul 2021 19:25:33 GMT, Andy Herrick wrote:
> JDK-8269387: jpackage --add-launcher should have option to not create
> shortcuts for additional launchers
src/jdk.jpackage/share/classes/jdk/jpackage/internal/AddLauncherArguments.java
line 39:
> 37:
> 38: /*
> 39: *
On Fri, 9 Jul 2021 17:59:35 GMT, Andy Herrick wrote:
>> JDK-8269387: jpackage --add-launcher should have option to not create
>> shortcuts for additional launchers
>
> Andy Herrick has updated the pull request incrementally with one additional
> commit since the last revision:
>
>
On Thu, 8 Jul 2021 19:25:33 GMT, Andy Herrick wrote:
> JDK-8269387: jpackage --add-launcher should have option to not create
> shortcuts for additional launchers
src/jdk.jpackage/share/classes/jdk/jpackage/internal/AppImageFile.java line 259:
> 257: for (var name : names) {
> 258:
On Thu, 8 Jul 2021 19:25:33 GMT, Andy Herrick wrote:
> JDK-8269387: jpackage --add-launcher should have option to not create
> shortcuts for additional launchers
test/jdk/tools/jpackage/share/AddLShortcutTest.java line 2:
> 1: /*
> 2: * Copyright (c) 2018, 2020, Oracle and/or its affiliates.
On Thu, 8 Jul 2021 19:25:33 GMT, Andy Herrick wrote:
> JDK-8269387: jpackage --add-launcher should have option to not create
> shortcuts for additional launchers
Review
test/jdk/tools/jpackage/share/AddLShortcutTest.java line 46:
> 44: */
> 45:
> 46: /*
Why do you need two jtreg @test-s
On Fri, 30 Apr 2021 04:22:37 GMT, Alexander Matveev
wrote:
> jpackage should specify architecture for produced PKG files via
> hostArchitectures="x86_x64 or arm64". aarch64 installer will be installable
> on x64 without specifying hostArchitectures which is not correct and if
> install on
On Fri, 30 Apr 2021 20:19:25 GMT, Andy Herrick wrote:
> JDK-8266129: tools/jpackage/windows/WinInstallerIconTest.java hangs with
> fastdebug
>
> just disabling this test when vm.debug
Marked as reviewed by asemenyuk (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/3827
On Fri, 30 Apr 2021 15:25:13 GMT, Andy Herrick wrote:
> JDK-8266227: Fix help text for --mac-signing-keychain
Marked as reviewed by asemenyuk (Reviewer).
The changes seems to be covering more than what the title of the CR states.
Would it make sense to update the title accordingly?
On Mon, 3 May 2021 17:24:16 GMT, Alexander Matveev wrote:
>> test/jdk/tools/jpackage/macosx/HostArchPkgTest.java line 84:
>>
>>> 82: }
>>> 83:
>>> 84: public static void main(String[] args) throws Exception {
>>
>> Please don't use direct TKit.run() call. Use
>>
On Mon, 3 May 2021 17:30:15 GMT, Alexander Matveev wrote:
>> test/jdk/tools/jpackage/macosx/HostArchPkgTest.java line 57:
>>
>>> 55: Path distributionFile = cmd.unpackedPackageDirectory()
>>> 56: .toAbsolutePath()
>>> 57: .getParent()
>>
>> Why
On Mon, 3 May 2021 20:20:52 GMT, Alexey Semenyuk wrote:
>> Alexander Matveev has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8266179: [macos] jpackage should specify architecture for produced pkg
>>
On Mon, 3 May 2021 19:26:19 GMT, Alexander Matveev wrote:
>> jpackage should specify architecture for produced PKG files via
>> hostArchitectures="x86_x64 or arm64". aarch64 installer will be installable
>> on x64 without specifying hostArchitectures which is not correct and if
>> install on
On Sat, 1 May 2021 04:04:17 GMT, Alexander Matveev wrote:
>> jpackage should specify architecture for produced PKG files via
>> hostArchitectures="x86_x64 or arm64". aarch64 installer will be installable
>> on x64 without specifying hostArchitectures which is not correct and if
>> install on
On Sat, 1 May 2021 04:04:17 GMT, Alexander Matveev wrote:
>> jpackage should specify architecture for produced PKG files via
>> hostArchitectures="x86_x64 or arm64". aarch64 installer will be installable
>> on x64 without specifying hostArchitectures which is not correct and if
>> install on
On Mon, 3 May 2021 22:52:21 GMT, Alexander Matveev wrote:
>> jpackage should specify architecture for produced PKG files via
>> hostArchitectures="x86_x64 or arm64". aarch64 installer will be installable
>> on x64 without specifying hostArchitectures which is not correct and if
>> install on
On Fri, 30 Apr 2021 15:25:13 GMT, Andy Herrick wrote:
> JDK-8266227: Fix help text for --mac-signing-keychain
Marked as reviewed by asemenyuk (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/3819
On Mon, 8 Feb 2021 15:25:02 GMT, Aleksey Shipilev wrote:
>> After JDK-8254702, SonarCloud instance complains about blocks like these:
>> "Change this loop body so that it can be executed more than once."
>>
>> int initJvmlLauncherData(JvmlLauncherData* ptr) const {
>> // Store path
On Mon, 8 Feb 2021 08:49:17 GMT, Aleksey Shipilev wrote:
> SonarCloud instance reports as new warning after JDK-8254702:
>
> This branch can not be reached because the condition duplicates a previous
> condition in the same sequence of "if/else if" statements.
>
> char*
Remove needless `#ifdef __cplusplus` from .cpp sources
-
Commit messages:
- 8223188: Consider rewriting in C++ or moving to ".c" files
Changes: https://git.openjdk.java.net/jdk/pull/2466/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk=2466=00
Issue:
launcher code on other
> platforms.
> - `applaunchercommon`: code shared between launcher and launcher lib on Linux
> and launcher code on other platforms.
Alexey Semenyuk has updated the pull request incrementally with one additional
commit since the last revision:
8254702: jpac
launcher code on other
> platforms.
> - `applaunchercommon`: code shared between launcher and launcher lib on Linux
> and launcher code on other platforms.
Alexey Semenyuk has updated the pull request incrementally with one additional
commit since the last revision:
8254702: jpac
On Mon, 1 Feb 2021 18:35:54 GMT, Alexey Semenyuk wrote:
>>> "common" was perfectly enough until this change. Unfortunately we cant just
>>> drop new C sources in "common" dir because we don't want them to be
>>> compiled
On Tue, 9 Feb 2021 04:03:14 GMT, Ioi Lam wrote:
> The Bug Synopsis of 'Consider rewriting in C++ or moving to ".c" files' is
> unclear.
> I would request that the Bug Synopsis to be changed to "removed unnecessary
> #ifdef __cplusplus" before integrating this PR.
Bug Synopsis updated as
> Remove needless `#ifdef __cplusplus` from .cpp sources
Alexey Semenyuk has refreshed the contents of this pull request, and previous
commits have been removed. The incremental views will show differences compared
to the previous content of the PR. The pull request contains one new com
On Mon, 8 Feb 2021 22:26:22 GMT, Alexey Semenyuk wrote:
> Remove needless `#ifdef __cplusplus` from .cpp sources
> @alexeysemenyukoracle FYI, there was no need to force-push (or even push at
> all) to your branch. It doesn't matter at all what the commit message(s) of
>
On Mon, 8 Feb 2021 22:26:22 GMT, Alexey Semenyuk wrote:
> Remove needless `#ifdef __cplusplus` from .cpp sources
This pull request has now been integrated.
Changeset: 699a3cde
Author: Alexey Semenyuk
URL: https://git.openjdk.java.net/jdk/commit/699a3cde
Stats: 10 lines in 2 fi
On Tue, 9 Feb 2021 08:58:23 GMT, Aleksey Shipilev wrote:
>> After JDK-8254702, SonarCloud instance complains about blocks like these:
>> "Change this loop body so that it can be executed more than once."
>>
>> int initJvmlLauncherData(JvmlLauncherData* ptr) const {
>> // Store path
On Fri, 29 Jan 2021 07:31:55 GMT, Aleksey Shipilev wrote:
>> If you run x86 configuration (cross-compiled on x86_64), then many tests
>> would fail with:
>>
>> $ CONF=linux-x86-server-fastdebug make images run-test TEST=tools/jpackage
>> ...
>> can not load libgnomevfs-2.so
>> Exception in
On Mon, 1 Feb 2021 18:24:23 GMT, Erik Joelsson wrote:
>> "common" was perfectly enough until this change. Unfortunately we cant just
>> drop new C sources in "common" dir because we don't want them to be compiled
>> with g++. That is why need new common directory (applauncherlibcommon) for C
On Mon, 22 Mar 2021 13:03:10 GMT, Andy Herrick wrote:
> JDK-8263887: Re-create default icons
Marked as reviewed by asemenyuk (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/3118
On Mon, 22 Mar 2021 20:40:09 GMT, Andy Herrick wrote:
> JDK-8259926: Error in jpackage sample usage in the help text
Marked as reviewed by asemenyuk (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/3132
On Wed, 24 Mar 2021 11:00:53 GMT, Andy Herrick wrote:
> Restoring fix to JDK-8248904: Add support to jpackage for the Mac App Store.
Marked as reviewed by asemenyuk (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/3172
Hi Zlatin,
There are no plans to deprecate "jpackage.app-path" system property. It
will be available in the next LTS release.
- Alexey
On 3/20/2021 1:25 PM, Zlatin Balevsky wrote:
Hi,
In my application I need to know the absolute path of the executable
generated by jpackage at runtime. I
Add support for --about-url, --win-update-url and --win-help-url parameters
-
Commit messages:
- Remove unused import-s
- 8220266: add support for additional metadata in add/remove programs
Changes: https://git.openjdk.java.net/jdk/pull/3178/files
Webrev:
Add missing escape single quote (') and typo fix
-
Commit messages:
- 8264165: jpackage BasicTest fails after JDK-8220266: Check help text
contains plaform specific parameters
Changes: https://git.openjdk.java.net/jdk/pull/3193/files
Webrev:
401 - 500 of 631 matches
Mail list logo
