On Fri, 18 Jul 2025 20:04:57 GMT, Alexander Matveev
wrote:
>> Re-submission of https://github.com/openjdk/jdk/pull/25314 after merge
>> conflict was resolved. Old PR will be closed.
>>
>> All comments are addressed from old PR. Merge conflict was significant, so
>> it is like new fix.
>>
>>
On Fri, 18 Jul 2025 02:47:04 GMT, Alexander Matveev
wrote:
>> Re-submission of https://github.com/openjdk/jdk/pull/25314 after merge
>> conflict was resolved. Old PR will be closed.
>>
>> All comments are addressed from old PR. Merge conflict was significant, so
>> it is like new fix.
>>
>>
On Wed, 16 Jul 2025 02:01:57 GMT, Alexander Matveev
wrote:
>> Re-submission of https://github.com/openjdk/jdk/pull/25314 after merge
>> conflict was resolved. Old PR will be closed.
>>
>> All comments are addressed from old PR. Merge conflict was significant, so
>> it is like new fix.
>>
>>
On Wed, 16 Jul 2025 02:01:57 GMT, Alexander Matveev
wrote:
>> Re-submission of https://github.com/openjdk/jdk/pull/25314 after merge
>> conflict was resolved. Old PR will be closed.
>>
>> All comments are addressed from old PR. Merge conflict was significant, so
>> it is like new fix.
>>
>>
On Wed, 16 Jul 2025 02:01:57 GMT, Alexander Matveev
wrote:
>> Re-submission of https://github.com/openjdk/jdk/pull/25314 after merge
>> conflict was resolved. Old PR will be closed.
>>
>> All comments are addressed from old PR. Merge conflict was significant, so
>> it is like new fix.
>>
>>
On Wed, 9 Jul 2025 10:32:47 GMT, Pooja-DP wrote:
> Bug reference: https://bugs.openjdk.org/browse/JDK-8361697
>
> The following message is removed:
>
> `
> MSG_BundlerFailed=Error: Bundler "{1}" ({0}) failed to produce a package`
>
> Signed-off-by: Pooja.D.P1
Marked as reviewed by asemenyuk
On Tue, 15 Jul 2025 02:15:56 GMT, Alexander Matveev
wrote:
>> Maybe run jpackage with `--verbose` flag?
>
> [19:14:45.620] jdk.jpackage.internal.model.PackagerException:
> java.lang.ClassCastException: class com.sun.proxy.jdk.proxy1.$Proxy0 cannot
> be cast to class jdk.jpackage.internal.MacAp
On Tue, 15 Jul 2025 01:45:11 GMT, Alexander Matveev
wrote:
>> What is the full stack trace?
>
> It does not print call stack. Not sure why. Once I figure it I will update.
Maybe run jpackage with `--verbose` flag?
-
PR Review Comment: https://git.openjdk.org/jdk/pull/26173#discuss
On Mon, 14 Jul 2025 23:33:36 GMT, Alexander Matveev
wrote:
>> Try,
>>
>>
>> builder.task(MacCopyAppImageTaskID.SIGN_RUNTIME_BUNDLE)
>>
>> .appImageAction(MacPackagingPipeline::signApplicationBundle)
>> .add();
>
> Getting following excep
On Fri, 11 Jul 2025 16:44:05 GMT, Alexander Matveev
wrote:
>> Re-submission of https://github.com/openjdk/jdk/pull/25314 after merge
>> conflict was resolved. Old PR will be closed.
>>
>> All comments are addressed from old PR. Merge conflict was significant, so
>> it is like new fix.
>>
>>
On Fri, 11 Jul 2025 16:44:05 GMT, Alexander Matveev
wrote:
>> Re-submission of https://github.com/openjdk/jdk/pull/25314 after merge
>> conflict was resolved. Old PR will be closed.
>>
>> All comments are addressed from old PR. Merge conflict was significant, so
>> it is like new fix.
>>
>>
On Wed, 9 Jul 2025 01:27:32 GMT, Alexander Matveev wrote:
>> src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacPackagingPipeline.java
>> line 311:
>>
>>> 309: }
>>> 310:
>>> 311: private static void sign(AppImageBuildEnv>> MacApplicationLayout> env) throws IOException {
>>
>> I
On Thu, 10 Jul 2025 00:27:55 GMT, Alexander Matveev
wrote:
>> src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/RuntimeBundle-Info.plist.template
>> line 6:
>>
>>> 4:
>>> 5: CFBundleDevelopmentRegion
>>> 6: English
>>
>> I'm surprised there is no standard way to
On Wed, 9 Jul 2025 00:31:39 GMT, Alexander Matveev wrote:
>> src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacApplicationBuilder.java
>> line 184:
>>
>>> 182: }
>>> 183:
>>> 184: public String validatedBundleIdentifier() throws ConfigException {
>>
>> This method is private on
On Thu, 10 Jul 2025 01:30:19 GMT, Alexander Matveev
wrote:
> runtimeImageDir is a value of --runtime-image in case of runtime installer.
This duplicates `Package.predefinedAppImage()` function. In case of runtime
packaging, the "predefined app image" should be the value of `--runtime-image`.
On Wed, 9 Jul 2025 01:32:38 GMT, Alexander Matveev wrote:
> RUNTIME_PACKAGE_LAYOUT points to "Contents/Home". Bundle is "Contents/Home",
> "Contents/MacOS" and "Contents/Info.plist".
Right, so `RUNTIME_PACKAGE_LAYOUT` points to a bundle just like
[ApplicationLayoutUtils.MAC_APPLICATION_LAYOUT]
On Fri, 11 Jul 2025 19:57:54 GMT, Alexander Matveev
wrote:
> Test updated to expect `jpackage` to PASS in case of
> `--mac-signing-key-user-name` and FAIL in case of
> `-mac-app-image-sign-identity`. See explanation below.
>
> Case 1: Only common name of certificate is used (PASS):
> jpackage
On Mon, 7 Jul 2025 23:20:08 GMT, Alexander Matveev wrote:
>> Re-submission of https://github.com/openjdk/jdk/pull/25314 after merge
>> conflict was resolved. Old PR will be closed.
>>
>> All comments are addressed from old PR. Merge conflict was significant, so
>> it is like new fix.
>>
>> Fi
On Mon, 7 Jul 2025 23:20:08 GMT, Alexander Matveev wrote:
>> Re-submission of https://github.com/openjdk/jdk/pull/25314 after merge
>> conflict was resolved. Old PR will be closed.
>>
>> All comments are addressed from old PR. Merge conflict was significant, so
>> it is like new fix.
>>
>> Fi
On Mon, 7 Jul 2025 23:20:08 GMT, Alexander Matveev wrote:
>> Re-submission of https://github.com/openjdk/jdk/pull/25314 after merge
>> conflict was resolved. Old PR will be closed.
>>
>> All comments are addressed from old PR. Merge conflict was significant, so
>> it is like new fix.
>>
>> Fi
On Mon, 7 Jul 2025 23:20:08 GMT, Alexander Matveev wrote:
>> Re-submission of https://github.com/openjdk/jdk/pull/25314 after merge
>> conflict was resolved. Old PR will be closed.
>>
>> All comments are addressed from old PR. Merge conflict was significant, so
>> it is like new fix.
>>
>> Fi
On Mon, 7 Jul 2025 23:20:08 GMT, Alexander Matveev wrote:
>> Re-submission of https://github.com/openjdk/jdk/pull/25314 after merge
>> conflict was resolved. Old PR will be closed.
>>
>> All comments are addressed from old PR. Merge conflict was significant, so
>> it is like new fix.
>>
>> Fi
On Mon, 7 Jul 2025 23:20:08 GMT, Alexander Matveev wrote:
>> Re-submission of https://github.com/openjdk/jdk/pull/25314 after merge
>> conflict was resolved. Old PR will be closed.
>>
>> All comments are addressed from old PR. Merge conflict was significant, so
>> it is like new fix.
>>
>> Fi
On Mon, 7 Jul 2025 23:20:08 GMT, Alexander Matveev wrote:
>> Re-submission of https://github.com/openjdk/jdk/pull/25314 after merge
>> conflict was resolved. Old PR will be closed.
>>
>> All comments are addressed from old PR. Merge conflict was significant, so
>> it is like new fix.
>>
>> Fi
On Mon, 7 Jul 2025 23:20:08 GMT, Alexander Matveev wrote:
>> Re-submission of https://github.com/openjdk/jdk/pull/25314 after merge
>> conflict was resolved. Old PR will be closed.
>>
>> All comments are addressed from old PR. Merge conflict was significant, so
>> it is like new fix.
>>
>> Fi
On Mon, 7 Jul 2025 23:20:08 GMT, Alexander Matveev wrote:
>> Re-submission of https://github.com/openjdk/jdk/pull/25314 after merge
>> conflict was resolved. Old PR will be closed.
>>
>> All comments are addressed from old PR. Merge conflict was significant, so
>> it is like new fix.
>>
>> Fi
On Mon, 7 Jul 2025 23:20:08 GMT, Alexander Matveev wrote:
>> Re-submission of https://github.com/openjdk/jdk/pull/25314 after merge
>> conflict was resolved. Old PR will be closed.
>>
>> All comments are addressed from old PR. Merge conflict was significant, so
>> it is like new fix.
>>
>> Fi
On Mon, 7 Jul 2025 23:20:08 GMT, Alexander Matveev wrote:
>> Re-submission of https://github.com/openjdk/jdk/pull/25314 after merge
>> conflict was resolved. Old PR will be closed.
>>
>> All comments are addressed from old PR. Merge conflict was significant, so
>> it is like new fix.
>>
>> Fi
On Mon, 7 Jul 2025 23:20:08 GMT, Alexander Matveev wrote:
>> Re-submission of https://github.com/openjdk/jdk/pull/25314 after merge
>> conflict was resolved. Old PR will be closed.
>>
>> All comments are addressed from old PR. Merge conflict was significant, so
>> it is like new fix.
>>
>> Fi
On Mon, 7 Jul 2025 23:20:08 GMT, Alexander Matveev wrote:
>> Re-submission of https://github.com/openjdk/jdk/pull/25314 after merge
>> conflict was resolved. Old PR will be closed.
>>
>> All comments are addressed from old PR. Merge conflict was significant, so
>> it is like new fix.
>>
>> Fi
On Mon, 7 Jul 2025 23:20:08 GMT, Alexander Matveev wrote:
>> Re-submission of https://github.com/openjdk/jdk/pull/25314 after merge
>> conflict was resolved. Old PR will be closed.
>>
>> All comments are addressed from old PR. Merge conflict was significant, so
>> it is like new fix.
>>
>> Fi
61207
<https://bugs.openjdk.org/browse/JDK-8361207.> . The sanity checks
already finished with success. Are there more steps needed/any
requirements or can i create the PR now (after a rebase (-;) ?
Best regards,
Armin
Am Montag, Juni 30, 2025 20:22 CEST, schrieb Alexey Semenyuk
:
Arm
nsupported architectures.
@"Alexey Semenyuk" I've read the contribution guide. So, the next step
would be finding a Sponsor?
Best regards,
Armin
Am Montag, Juni 30, 2025 17:59 CEST, schrieb Alexey Semenyuk
:
Hi Armin,
Your ARM64 MSI contribution/enhancement for the jpackage
Hi Armin,
Your ARM64 MSI contribution/enhancement for the jpackage will be much
appreciated.
- Alexey
On 6/30/2025 10:09 AM, Armin Schrenk wrote:
Hello everyone,
does jpackage support building native ARM64 MSI packages? Building an
jpackage MSI on Windows ARM64, the resulting package cont
Hi Davide,
There is no such jpackage option that configures the installer to launch
the app automatically after installation.
You can, however, customize wix sources jpackage uses to build the
installer accordingly.
Here is how you can do it:
1. Use main.wxs file from [1] as the baseline f
On Tue, 27 May 2025 19:48:11 GMT, Stefan Lobbenmeier wrote:
>> The documentation suggests that --linux-package-deps is a boolean option,
>> while in fact it is a string option with dependencies separated by comma and
>> space
>>
>> You can tell that this option is supposed to have an argument
On Tue, 27 May 2025 19:48:11 GMT, Stefan Lobbenmeier wrote:
>> The documentation suggests that --linux-package-deps is a boolean option,
>> while in fact it is a string option with dependencies separated by comma and
>> space
>>
>> You can tell that this option is supposed to have an argument
On Wed, 21 May 2025 12:38:19 GMT, Stefan Lobbenmeier wrote:
>> Thank you for making the change! Other property files and jpackage.md should
>> also be updated to sync them with HelpResources.properties.
>
>> Thank you for making the change! Other property files and jpackage.md should
>> also be
On Fri, 30 May 2025 01:45:41 GMT, Alexander Matveev
wrote:
>> - `--install-dir` option in DMG packaging is no longer ignored.
>> - Defaults are still the same: `/Applications` and
>> `/Library/Java/JavaVirtualMachines`.
>> - It will be user responsibility to make sure installation directory exi
On Wed, 28 May 2025 03:35:40 GMT, Alexey Semenyuk wrote:
> Various enhancements of jpackage test helpers:
> - Can run fa tests when JAVA_TOOL_OPTIONS env variable contains
> `--module-path` option. This change makes support for
> `jpackage.test.clear-app-launcher-java-env-
On Wed, 28 May 2025 03:35:40 GMT, Alexey Semenyuk wrote:
> Various enhancements of jpackage test helpers:
> - Can run fa tests when JAVA_TOOL_OPTIONS env variable contains
> `--module-path` option. This change makes support for
> `jpackage.test.clear-app-launcher-java-env-
Various enhancements of jpackage test helpers:
- Can run fa tests when JAVA_TOOL_OPTIONS env variable contains
`--module-path` option. This change makes support for
`jpackage.test.clear-app-launcher-java-env-vars` system property redundant.
- Rework JUnitAdapter to make it run jpackage TestInst
On Wed, 28 May 2025 03:35:40 GMT, Alexey Semenyuk wrote:
> Various enhancements of jpackage test helpers:
> - Can run fa tests when JAVA_TOOL_OPTIONS env variable contains
> `--module-path` option. This change makes support for
> `jpackage.test.clear-app-launcher-java-env-
On Wed, 28 May 2025 22:30:25 GMT, Alexey Semenyuk wrote:
>> - `--install-dir` option in DMG packaging is no longer ignored.
>> - Defaults are still the same: `/Applications` and
>> `/Library/Java/JavaVirtualMachines`.
>> - If the installation directory doesn't exist
On Wed, 28 May 2025 21:40:08 GMT, Alexander Matveev
wrote:
> If we do not have empty scripts how user will override it?
What is the problem with this? By default, PKG will not have scripts. If they
place them in the resource directory, jpackage will use them.
-
PR Comment: https:
On Wed, 28 May 2025 07:11:36 GMT, Alexander Matveev
wrote:
> If the installation directory doesn't exist, jpackage will try to create and
> delete it right after the DMG package is created.
Is this absolutely necessary? Is there a better way?
It looks like you removed DMG-specific runtime ins
On Wed, 28 May 2025 07:11:36 GMT, Alexander Matveev
wrote:
> - `--install-dir` option in DMG packaging is no longer ignored.
> - Defaults are still the same: `/Applications` and
> `/Library/Java/JavaVirtualMachines`.
> - If the installation directory doesn't exist, jpackage will try to create
On Wed, 28 May 2025 19:32:47 GMT, Alexander Matveev
wrote:
> - Removed all code from pre- and post- installation PKG scripts.
> - This code is not needed and PKG should create destination folder and set
> correct permissions.
> - If for some reason it is not happens, permissions issues should b
On Wed, 28 May 2025 02:52:57 GMT, Alexey Semenyuk wrote:
> - Extract ExternalApplication interface from AppImageFile and add it to the
> model;
> - Move LauncherData.ModuleInfo class to the top level;
> - Add parent interface BundleSpec for Application and Package interfaces in
On Wed, 28 May 2025 06:57:15 GMT, Alexander Matveev
wrote:
>> Alexey Semenyuk has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Fix typo
>
> src/jdk.jpackage/share/classes/jdk/jpackage/internal/FromP
icationWriter into BundleCreator interface;
> - Add BundlingEnvironment, and BundlingOperation interfaces to the model;
> - Remove LauncherModularStartupInfoMixin.modulePath(). It is not being used;
> - Remove CollectionUtils.toSet();
>
> Additionally, fix modifier order in TokenReplace.
- Extract ExternalApplication interface from AppImageFile and add it to the
model;
- Move LauncherData.ModuleInfo class to the top level;
- Add parent interface BundleSpec for Application and Package interfaces in
the model;
- Merge PackageWriter and ApplicationWriter into BundleCreator interf
On Tue, 27 May 2025 19:48:11 GMT, Stefan Lobbenmeier wrote:
>> The documentation suggests that --linux-package-deps is a boolean option,
>> while in fact it is a string option with dependencies separated by comma and
>> space
>>
>> You can tell that this option is supposed to have an argument
On Fri, 23 May 2025 11:40:24 GMT, Sorna Sarathi N wrote:
> Adds missing classpath exception in a couple of files.
Thank you for fixing this! My sincere apologies for the trouble.
-
PR Comment: https://git.openjdk.org/jdk/pull/25413#issuecomment-2905075388
On Fri, 23 May 2025 11:40:24 GMT, Sorna Sarathi N wrote:
> Adds missing classpath exception in a couple of files.
Marked as reviewed by asemenyuk (Reviewer).
-
PR Review: https://git.openjdk.org/jdk/pull/25413#pullrequestreview-2865019628
On Thu, 22 May 2025 19:39:04 GMT, Alexey Semenyuk wrote:
> - Allow to configure multiple expected installation exit codes for jpackage
> native packaging tests.
> - Adjusted the test to get skipped if executed in a restricted environment
> that doesn't allow per-user inst
- Allow to configure multiple expected installation exit codes for jpackage
native packaging tests.
- Adjusted the test to get skipped if executed in a restricted environment
that doesn't allow per-user installations for non-administrators.
-
Commit messages:
- 8357171: Test tools
On Thu, 22 May 2025 19:39:04 GMT, Alexey Semenyuk wrote:
> - Allow to configure multiple expected installation exit codes for jpackage
> native packaging tests.
> - Adjusted the test to get skipped if executed in a restricted environment
> that doesn't allow per-user inst
On Wed, 21 May 2025 20:17:45 GMT, Stefan Lobbenmeier wrote:
>> src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/HelpResources.properties
>> line 298:
>>
>>> 296: \ --linux-menu-group \n\
>>> 297: \ Menu group this application is placed in\n\
>>> 298: \ --linux-package-d
On Wed, 21 May 2025 16:26:39 GMT, Alexey Semenyuk wrote:
> Add a missing line to the copyright header
This pull request has now been integrated.
Changeset: 6546de1d
Author: Alexey Semenyuk
URL:
https://git.openjdk.org/jdk/commit/6546de1d3adb8c4755950ee6fb858ec9ee1c5294
Stats:
Add a missing line to the copyright header
-
Commit messages:
- 8357478: Fix copyright header in
src/jdk.jpackage/share/classes/jdk/jpackage/internal/AppImageDesc.java
Changes: https://git.openjdk.org/jdk/pull/25362/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25362&ran
On Wed, 12 Jun 2024 01:37:19 GMT, Alexey Semenyuk wrote:
> Refactor jpackage to separate the configuration and execution phases.
> At the configuration phase, jpackage parses command-line arguments and
> validates them.
> At the execution phase, jpackage builds a bundle based on da
On Wed, 21 May 2025 12:41:24 GMT, Stefan Lobbenmeier wrote:
>> The documentation suggests that --linux-package-deps is a boolean option,
>> while in fact it is a string option with dependencies separated by comma and
>> space
>>
>> You can tell that this option is supposed to have an argument
On Wed, 21 May 2025 10:00:39 GMT, Stefan Lobbenmeier wrote:
>> The documentation suggests that --linux-package-deps is a boolean option,
>> while in fact it is a string option with dependencies separated by comma and
>> space
>>
>> You can tell that this option is supposed to have an argument
On Wed, 21 May 2025 10:00:39 GMT, Stefan Lobbenmeier wrote:
>> The documentation suggests that --linux-package-deps is a boolean option,
>> while in fact it is a string option with dependencies separated by comma and
>> space
>>
>> You can tell that this option is supposed to have an argument
On Wed, 21 May 2025 10:00:03 GMT, Stefan Lobbenmeier wrote:
> As in, this worked in my testing: --linux-package-deps "foo, bar"
Of course. You can put any string for `--linux-package-deps` option, jpackage
will pass it as-is to the underlying tool. Unlike, e.g. `--arguments`, for
which jpackag
On Wed, 21 May 2025 11:15:08 GMT, Stefan Lobbenmeier wrote:
> Also maybe one follow up question - what do I need to do so the change
> appears in older versions like
You need to backport this fix once it is integrated.
-
PR Comment: https://git.openjdk.org/jdk/pull/23638#issuecomm
On Wed, 21 May 2025 02:19:31 GMT, Alexander Matveev
wrote:
>> Fixed jpackage to produce valid Java runtimes based on description below:
>>
>> Definitions:
>>
>> - JDK bundle defined as bundle which contains "Contents/Home",
>> "Contents/MacOS/libjli.dylib" and "Contents/Info.plist".
>> - Sign
On Wed, 21 May 2025 01:44:48 GMT, Alexander Matveev
wrote:
>> src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WinMsiBundler.java
>> line 199:
>>
>>> 197: }
>>> 198: return version;
>>> 199: },
>>
>> I guess, this is a
On Wed, 21 May 2025 01:24:16 GMT, Alexander Matveev
wrote:
>> src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/MacResources.properties
>> line 88:
>>
>>> 86: message.codesign.failed.reason.xcode.tools=Possible reason for
>>> "codesign" failure is missing Xcode with command line
On Tue, 20 May 2025 00:47:09 GMT, Alexander Matveev
wrote:
> Fixed jpackage to produce valid Java runtimes based on description below:
>
> Definitions:
>
> - JDK bundle defined as bundle which contains "Contents/Home",
> "Contents/MacOS/libjli.dylib" and "Contents/Info.plist".
> - Signed JDK
On Tue, 20 May 2025 00:47:09 GMT, Alexander Matveev
wrote:
> Fixed jpackage to produce valid Java runtimes based on description below:
>
> Definitions:
>
> - JDK bundle defined as bundle which contains "Contents/Home",
> "Contents/MacOS/libjli.dylib" and "Contents/Info.plist".
> - Signed JDK
On Tue, 20 May 2025 00:47:09 GMT, Alexander Matveev
wrote:
> Fixed jpackage to produce valid Java runtimes based on description below:
>
> Definitions:
>
> - JDK bundle defined as bundle which contains "Contents/Home",
> "Contents/MacOS/libjli.dylib" and "Contents/Info.plist".
> - Signed JDK
On Tue, 20 May 2025 00:47:09 GMT, Alexander Matveev
wrote:
> Fixed jpackage to produce valid Java runtimes based on description below:
>
> Definitions:
>
> - JDK bundle defined as bundle which contains "Contents/Home",
> "Contents/MacOS/libjli.dylib" and "Contents/Info.plist".
> - Signed JDK
On Fri, 14 Feb 2025 15:01:35 GMT, Stefan Lobbenmeier wrote:
> The documentation suggests that --linux-package-deps is a boolean option,
> while in fact it is a string option with dependencies separated by comma and
> space
>
> You can tell that this option is supposed to have an argument here:
On Tue, 20 May 2025 00:47:09 GMT, Alexander Matveev
wrote:
> Fixed jpackage to produce valid Java runtimes based on description below:
>
> Definitions:
>
> - JDK bundle defined as bundle which contains "Contents/Home",
> "Contents/MacOS/libjli.dylib" and "Contents/Info.plist".
> - Signed JDK
On Tue, 20 May 2025 00:47:09 GMT, Alexander Matveev
wrote:
> Fixed jpackage to produce valid Java runtimes based on description below:
>
> Definitions:
>
> - JDK bundle defined as bundle which contains "Contents/Home",
> "Contents/MacOS/libjli.dylib" and "Contents/Info.plist".
> - Signed JDK
On Sat, 10 May 2025 19:02:45 GMT, Alexey Semenyuk wrote:
>> Refactor jpackage to separate the configuration and execution phases.
>> At the configuration phase, jpackage parses command-line arguments and
>> validates them.
>> At the execution phase, jpackage build
> Refactor jpackage to separate the configuration and execution phases.
> At the configuration phase, jpackage parses command-line arguments and
> validates them.
> At the execution phase, jpackage builds a bundle based on data collected at
> the configuration phase.
>
> There was no clear separ
On Tue, 13 May 2025 01:55:19 GMT, Alexander Matveev
wrote:
>> Alexey Semenyuk has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 512 commits:
>>
>> - Add ConfigFilesStasher that allows to save co
On Sat, 10 May 2025 19:02:45 GMT, Alexey Semenyuk wrote:
>> Refactor jpackage to separate the configuration and execution phases.
>> At the configuration phase, jpackage parses command-line arguments and
>> validates them.
>> At the execution phase, jpackage build
On Tue, 13 May 2025 00:30:08 GMT, Alexander Matveev
wrote:
> `openssl` from macOS will ignore `faketime` and as result expired
> certificates will not be generated correctly. By default we should use these
> tools from Homebrew.
Marked as reviewed by asemenyuk (Reviewer).
-
PR R
> Refactor jpackage to separate the configuration and execution phases.
> At the configuration phase, jpackage parses command-line arguments and
> validates them.
> At the execution phase, jpackage builds a bundle based on data collected at
> the configuration phase.
>
> There was no clear separ
On Fri, 9 May 2025 23:36:44 GMT, Alexander Matveev wrote:
> - Regression from JDK-8352480.
> - On macOS we should create `Links` folder under `Resources`. Which means
> `--app-content` should point to `app-content/Resources` and not to
> `app-content/Resources/Links`.
Marked as reviewed by ase
> Refactor jpackage to separate the configuration and execution phases.
> At the configuration phase, jpackage parses command-line arguments and
> validates them.
> At the execution phase, jpackage builds a bundle based on data collected at
> the configuration phase.
>
> There was no clear separ
> Refactor jpackage to separate the configuration and execution phases.
> At the configuration phase, jpackage parses command-line arguments and
> validates them.
> At the execution phase, jpackage builds a bundle based on data collected at
> the configuration phase.
>
> There was no clear separ
Refactor jpackage to separate the configuration and execution phases.
At the configuration phase, jpackage parses command-line arguments and
validates them.
At the execution phase, jpackage builds a bundle based on data collected at the
configuration phase.
There was no clear separation between
On Wed, 12 Jun 2024 01:37:19 GMT, Alexey Semenyuk wrote:
> Refactor jpackage to separate the configuration and execution phases.
> At the configuration phase, jpackage parses command-line arguments and
> validates them.
> At the execution phase, jpackage builds a bundle based on da
On Fri, 9 May 2025 01:39:07 GMT, Alexander Matveev wrote:
>> - Symbolic links will not be followed for `--app-content` on all platforms.
>> - Added test to cover this case.
>> - `MacHelper` updated to use "cp -R" instead of "cp -r" when unpacking DMG,
>> since "cp -r" on macOS is not documented
On Fri, 9 May 2025 00:10:34 GMT, Alexander Matveev wrote:
>> test/jdk/tools/jpackage/share/AppContentTest.java line 116:
>>
>>> 114: private static Path getAppContentPath(JPackageCommand cmd, Path
>>> name) {
>>> 115: Path contentDir = cmd.appLayout().contentDirectory();
>>> 116:
On Thu, 8 May 2025 20:19:43 GMT, Alexey Semenyuk wrote:
> Add a check that jpackage doesn't modify files/directories supplied with
> "--app-image", "--resource-dir", "--runtime-image", "--app-content", and
> "--mac-dmg-content"
On Thu, 8 May 2025 17:23:48 GMT, Alexey Semenyuk wrote:
> Fix JPackageCommand.assertAppImageFile() method to make it pass the relative
> path to ".jpackag.xml" file to JPackageCommand.assertFileInAppImage().
This pull request has now been integrated.
Changeset: 8a8893ec
A
Add a check that jpackage doesn't modify files/directories supplied with
"--app-image", "--resource-dir", "--runtime-image", "--app-content", and
"--mac-dmg-content" options to every jpackage test.
-
Commit messages:
- Verify jpackage doesn't modify external directories passed to j
On Thu, 8 May 2025 20:19:43 GMT, Alexey Semenyuk wrote:
> Add a check that jpackage doesn't modify files/directories supplied with
> "--app-image", "--resource-dir", "--runtime-image", "--app-content", and
> "--mac-dmg-c
On Thu, 8 May 2025 17:23:48 GMT, Alexey Semenyuk wrote:
> Fix JPackageCommand.assertAppImageFile() method to make it pass the relative
> path to ".jpackag.xml" file to JPackageCommand.assertFileInAppImage().
@sashamatveev PTAL
-
PR Comment: https://git.openjdk.or
Fix JPackageCommand.assertAppImageFile() method to make it pass the relative
path to ".jpackag.xml" file to JPackageCommand.assertFileInAppImage().
-
Commit messages:
- Fix a bug in JPackageCommand.assertFileInAppImage() uncovered by running
signing tests after JDK-8356219 fix. JDK
On Wed, 7 May 2025 02:07:03 GMT, Alexander Matveev wrote:
>> - Symbolic links will not be followed for `--app-content` on all platforms.
>> - Added test to cover this case.
>> - `MacHelper` updated to use "cp -R" instead of "cp -r" when unpacking DMG,
>> since "cp -r" on macOS is not documented
On Fri, 25 Apr 2025 18:07:50 GMT, Alexey Semenyuk wrote:
> Fix issues uncovered in the tests after local test runs with the installation
> of test packages:
> - LinuxHelper: fix a regression from
> [JDK-8354988](https://bugs.openjdk.org/browse/JDK-8354988). Before the
> [JDK
Fix issues uncovered in the tests after local test runs with the installation
of test packages:
- LinuxHelper: fix a regression from
[JDK-8354988](https://bugs.openjdk.org/browse/JDK-8354988). Before the
[JDK-8354988](https://bugs.openjdk.org/browse/JDK-8354988) fix, when a process
started wit
On Fri, 25 Apr 2025 18:07:50 GMT, Alexey Semenyuk wrote:
> Fix issues uncovered in the tests after local test runs with the installation
> of test packages:
> - LinuxHelper: fix a regression from
> [JDK-8354988](https://bugs.openjdk.org/browse/JDK-8354988). Before the
> [JDK
1 - 100 of 744 matches
Mail list logo
