Integrated: 8286122: [macos]: App bundle cannot upload to Mac App Store due to info.plist embedded in java exe
On Wed, 11 May 2022 21:31:44 GMT, Alexander Matveev wrote: > - It is not possible to support native JDK commands such as "java" inside Mac > App Store bundles due to embedded info.plist. Workarounds suggested in > JDK-8286122 does not seems to be visible. > - With proposed fix we will enforce "--strip-native-commands" option for > jlink, so native JDK commands are not included when generating Mac App Store > bundles. > - Custom runtime provided via --runtime-image should not contain native > commands as well, otherwise jpackage will throw error. > - Added two tests to validate fix. This pull request has now been integrated. Changeset: b523c884 Author:Alexander Matveev URL: https://git.openjdk.java.net/jdk/commit/b523c88480ba5c8f9d78537c9de0abcbf1f867c0 Stats: 221 lines in 7 files changed: 216 ins; 1 del; 4 mod 8286122: [macos]: App bundle cannot upload to Mac App Store due to info.plist embedded in java exe Reviewed-by: asemenyuk, kcr - PR: https://git.openjdk.java.net/jdk/pull/8666
Re: RFR: JDK-8236128: Allow jpackage create installers for services
On Fri, 11 Mar 2022 23:37:06 GMT, Alexey Semenyuk wrote: > Implementation of [JDK-8275062: "Allow jpackage create installers for > services"](https://bugs.openjdk.java.net/browse/JDK-8275062) > CSR Marked as reviewed by almatvee (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/7793
Re: RFR: 8277429: Conflicting jpackage static library name
On Sat, 20 Nov 2021 03:26:51 GMT, Alexey Semenyuk wrote: > 8277429: Conflicting jpackage static library name Marked as reviewed by almatvee (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/6485
Re: RFR: 8254702: jpackage app launcher crashes on CentOS [v2]
On Fri, 29 Jan 2021 23:06:20 GMT, Alexey Semenyuk 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++ code from app launcher. >> At startup app launcher loads launcher shared lib and calls functions it >> provides to get data for launching JVM (path to jli lib and arguments for >> JLI_Launch function call). >> App launcher unloads launcher shared lib before launching JVM to remove C++ >> runtime from the process memory. >> >> Getting rid of C++ code from app launcher required to rewrite app >> installation location lookup code from C++ to C. LinuxPackage.c source is C >> alternative for >> https://github.com/openjdk/jdk/blob/master/src/jdk.jpackage/linux/native/applauncher/Package.cpp >> and >> https://github.com/openjdk/jdk/blob/master/src/jdk.jpackage/linux/native/applauncher/Executor.cpp. >> >> Layout of jpackage's native code changed: >> - `common`: code shared between all jpackage binaries. >> - `applauncher`: launcher only code. >> - `applauncherlib`: launcher lib code on Linux and 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 will show differences > compared to the previous content of the PR. Marked as reviewed by almatvee (Committer). - PR: https://git.openjdk.java.net/jdk/pull/2320
Re: RFR: JDK-8252870: Finalize (remove "incubator" from) jpackage [v2]
On Tue, 13 Oct 2020 14:48:40 GMT, Andy Herrick wrote: >> JDK-8252870: Finalize (remove "incubator" from) jpackage > > Andy Herrick has updated the pull request incrementally with one additional > commit since the last revision: > > JDK-8252870: Finalize (remove "incubator" from) jpackage > - reverting two auto-generated files, and changing module-info to "@since > 16" Marked as reviewed by almatvee (Committer). - PR: https://git.openjdk.java.net/jdk/pull/633
Re: RFR: JDK-8252870: Finalize (remove "incubator" from) jpackage [v2]
On Tue, 13 Oct 2020 14:48:40 GMT, Andy Herrick wrote: >> JDK-8252870: Finalize (remove "incubator" from) jpackage > > Andy Herrick has updated the pull request incrementally with one additional > commit since the last revision: > > JDK-8252870: Finalize (remove "incubator" from) jpackage > - reverting two auto-generated files, and changing module-info to "@since > 16" src/jdk.jpackage/linux/classes/module-info.java.extra line 29: > 27: jdk.jpackage.internal.LinuxAppBundler, > 28: jdk.jpackage.internal.LinuxDebBundler, > 29: jdk.jpackage.internal.LinuxRpmBundler; Not sure why it was changed. Looks like git recorded file renaming incorrectly. src/jdk.jpackage/macosx/classes/module-info.java.extra line 30: > 28: jdk.jpackage.internal.MacAppStoreBundler, > 29: jdk.jpackage.internal.MacDmgBundler, > 30: jdk.jpackage.internal.MacPkgBundler; Looks like another rename issue. src/jdk.jpackage/windows/classes/module-info.java.extra line 29: > 27: jdk.jpackage.internal.WinAppBundler, > 28: jdk.jpackage.internal.WinExeBundler, > 29: jdk.jpackage.internal.WinMsiBundler; Another rename issue. - PR: https://git.openjdk.java.net/jdk/pull/633
Re: RFR: JDK-8214566 : --win-dir-chooser does not prompt if destination folder is not empty
Hi Erik, http://cr.openjdk.java.net/~almatvee/8214566/webrev.01/ - Removed $(call SET_SHARED_LIBRARY_ORIGIN), TOOLCHAIN_LINK_CXX and linking with libjava. Thanks, Alexander On 3/7/2019 6:52 AM, Erik Joelsson wrote: Hello Alexander, A few notes: $(call SET_SHARED_LIBRARY_ORIGIN) and TOOLCHAIN_LINK_CXX have no effect on Windows, so should be removed to avoid confusion in the future. This new library does not link with libjava so I see no need to add that prerequisite declaration. /Erik On 2019-03-06 17:10, 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 custom action to check installation folder and display confirmation dialog to ask user to continue installation if destination folder is not empty. This is same behavior and confirmation message as for .exe. [1] https://bugs.openjdk.java.net/browse/JDK-8214566 [2] http://cr.openjdk.java.net/~almatvee/8214566/webrev.00/ Thanks, Alexander
RFR: JDK-8214566 : --win-dir-chooser does not prompt if destination folder is not empty
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 custom action to check installation folder and display confirmation dialog to ask user to continue installation if destination folder is not empty. This is same behavior and confirmation message as for .exe. [1] https://bugs.openjdk.java.net/browse/JDK-8214566 [2] http://cr.openjdk.java.net/~almatvee/8214566/webrev.00/ Thanks, Alexander
Re: RFR: JDK-8212091 : Move native code under platform specific folders and files
Hi Roger, Some deleted files are actually deleted files, since I did code cleanup as well. Added files contain code from splitting original source files. This was needed to re-arrange code. Not sure how to log with hg file split. Also, we already moved files without keeping history, since we are not planing to keep history when moving jpackage from sandbox. Thanks, Alexander On 2/19/2019 8:49 AM, Roger Riggs wrote: Hi Alexander, Some files appear to be moved with hg, but others are copied and deleted. Please use hg mv to retain the continuity of the history. Thanks, Roger On 02/15/2019 10:03 PM, Alexander Matveev wrote: Hi Magnus, http://cr.openjdk.java.net/~almatvee/8212091/webrev.01/ Moved all files from "posix" to "unix" folder and reverted Lib-jdk.jpackage.gmk changes. Webrev updated with files moved, instead of add/remove. Thanks, Alexander On 2/14/2019 11:44 PM, Magnus Ihse Bursie wrote: On 2019-02-15 04:31, 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). - Moved native code under platform specific folder. - Removed most usage on #ifdefs for WINDOWS, LINUX, MAC and POSIX. - MAC define is still used in JavaVirtualMachine.cpp and Package.cpp for Mac specific code to filter out some arguments. I decided to keep it as is for now, since Mac specific code is small. - Defines are used in Platform.cpp to initialize platform specific classes. - Removed all pragma warning and fixed all compilation warnings. - Removed unused code. [1] https://bugs.openjdk.java.net/browse/JDK-8212091 [2] http://cr.openjdk.java.net/~almatvee/8212091/webrev.00/ The JDK standard is to use "unix", not "posix", for the shared functionality between linux/solaris/macosx. You can keep the name "PosixPlatform.*" if you want, though; the important thing is the directory name. Also, if you do that, you do not need any changes to make/lib/Lib-jdk.jpackage.gmk, since that will be automatically understood by the build system. It looks from the webrev that you have "moved" the files by doing "hg add" and "hg remove". Please use "hg move" instead -- this will keep history intact, and it allows reviewers to see if you have also made changes to the moved files. (If you do have modified the moved file, reverting a "hg add+hg remove" process is a bit more tricky -- you need to do "hg forget" on the new file, rename it to something else (otherwise "hg move" will complain), "hg revert" the old file back in place, do a "hg move" from the old to the new, and then copy the modified, renamed file back over the target new file again.) /Magnus Thanks, Alexander
Re: RFR: JDK-8212091 : Move native code under platform specific folders and files
Hi Magnus, http://cr.openjdk.java.net/~almatvee/8212091/webrev.01/ Moved all files from "posix" to "unix" folder and reverted Lib-jdk.jpackage.gmk changes. Webrev updated with files moved, instead of add/remove. Thanks, Alexander On 2/14/2019 11:44 PM, Magnus Ihse Bursie wrote: On 2019-02-15 04:31, 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). - Moved native code under platform specific folder. - Removed most usage on #ifdefs for WINDOWS, LINUX, MAC and POSIX. - MAC define is still used in JavaVirtualMachine.cpp and Package.cpp for Mac specific code to filter out some arguments. I decided to keep it as is for now, since Mac specific code is small. - Defines are used in Platform.cpp to initialize platform specific classes. - Removed all pragma warning and fixed all compilation warnings. - Removed unused code. [1] https://bugs.openjdk.java.net/browse/JDK-8212091 [2] http://cr.openjdk.java.net/~almatvee/8212091/webrev.00/ The JDK standard is to use "unix", not "posix", for the shared functionality between linux/solaris/macosx. You can keep the name "PosixPlatform.*" if you want, though; the important thing is the directory name. Also, if you do that, you do not need any changes to make/lib/Lib-jdk.jpackage.gmk, since that will be automatically understood by the build system. It looks from the webrev that you have "moved" the files by doing "hg add" and "hg remove". Please use "hg move" instead -- this will keep history intact, and it allows reviewers to see if you have also made changes to the moved files. (If you do have modified the moved file, reverting a "hg add+hg remove" process is a bit more tricky -- you need to do "hg forget" on the new file, rename it to something else (otherwise "hg move" will complain), "hg revert" the old file back in place, do a "hg move" from the old to the new, and then copy the modified, renamed file back over the target new file again.) /Magnus Thanks, Alexander
RFR: JDK-8212091 : Move native code under platform specific folders and files
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). - Moved native code under platform specific folder. - Removed most usage on #ifdefs for WINDOWS, LINUX, MAC and POSIX. - MAC define is still used in JavaVirtualMachine.cpp and Package.cpp for Mac specific code to filter out some arguments. I decided to keep it as is for now, since Mac specific code is small. - Defines are used in Platform.cpp to initialize platform specific classes. - Removed all pragma warning and fixed all compilation warnings. - Removed unused code. [1] https://bugs.openjdk.java.net/browse/JDK-8212091 [2] http://cr.openjdk.java.net/~almatvee/8212091/webrev.00/ Thanks, Alexander
Re: RFR: JDK-8217317 : Create jpackage native library for windows
Hi Magnus, http://cr.openjdk.java.net/~almatvee/8217317/webrev.01/ Moved files to libjpackage and remove JPACKAGELIB_SRC. Old wmain() was in jpackage.cpp line 461. Thanks, Alexander On 2/1/2019 3:39 AM, Magnus Ihse Bursie wrote: Hi Alexander, On 2019-02-01 05:22, 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). - jpackage launcher will now build same as Linux and OS X using SetupBuildLauncher. - jpackage.dll was added based on Windows jpackage.exe launcher which will have icon swap and version swap functionality called via JNI. - Some code formatting, clean up and minor improvements where done to icon and version swap code. No functional changes. - Windows registry will be read and enumerated via JNI as well. - isDirectoryInExclusionPath() will use native path comparison, since paths in registry and temp folder returned by Java code can be in short or long format, thus simple string comparison will not work. - Windows Defender workaround warning will be checked for --build-root as well if it is set. - Removed extra escaping from JPackageHelper for Windows, otherwise tests fails due to incorrect escaping. Our launcher used CreateProcess to launch java.exe by passing args from main() to CreateProcess. This is why I think we required extra escaping. [1] https://bugs.openjdk.java.net/browse/JDK-8217317 [2] http://cr.openjdk.java.net/~almatvee/8217317/webrev.00/ It basically looks good from a build perspective. There is one change I'd like to request, however, and that is that you place the source code according to the standard layout. This means moving the source files from src/jdk.jpackage/windows/native/jpackage to src/jdk.jpackage/windows/native/libjpackage. Also, when you do this, you don't need JPACKAGELIB_SRC; the location of the files will be determined by SetupJdkLibrary based on the name "jpackage" of the library. I'm also surprised to see that I can't find the removal of the old WinMain() method? /Magnus Thanks, Alexander
RFR: JDK-8217317 : Create jpackage native library for windows
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). - jpackage launcher will now build same as Linux and OS X using SetupBuildLauncher. - jpackage.dll was added based on Windows jpackage.exe launcher which will have icon swap and version swap functionality called via JNI. - Some code formatting, clean up and minor improvements where done to icon and version swap code. No functional changes. - Windows registry will be read and enumerated via JNI as well. - isDirectoryInExclusionPath() will use native path comparison, since paths in registry and temp folder returned by Java code can be in short or long format, thus simple string comparison will not work. - Windows Defender workaround warning will be checked for --build-root as well if it is set. - Removed extra escaping from JPackageHelper for Windows, otherwise tests fails due to incorrect escaping. Our launcher used CreateProcess to launch java.exe by passing args from main() to CreateProcess. This is why I think we required extra escaping. [1] https://bugs.openjdk.java.net/browse/JDK-8217317 [2] http://cr.openjdk.java.net/~almatvee/8217317/webrev.00/ Thanks, Alexander
