On Sat, 5 Apr 2025 04:49:03 GMT, Christoph Langer wrote:
>> Severin Gehwolf 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 four additional
>> c
On Wed, 9 Apr 2025 16:10:20 GMT, Severin Gehwolf wrote:
>> For JEP 493-enabled builds there are no JMODs. Certain files come from the
>> installed JDK image when a user creates a custom run-time from it. This is
>> problematic for example for files that often come from a different package
>> (
On Mon, 7 Apr 2025 13:35:57 GMT, Severin Gehwolf wrote:
>> For JEP 493-enabled builds there are no JMODs. Certain files come from the
>> installed JDK image when a user creates a custom run-time from it. This is
>> problematic for example for files that often come from a different package
>> (
On Mon, 7 Apr 2025 12:21:06 GMT, Severin Gehwolf wrote:
>> test/jdk/tools/jlink/runtimeImage/UpgradeableFileCacertsTest.java line 42:
>>
>>> 40: /*
>>> 41: * @test
>>> 42: * @summary Verify that no errors are reported for files the have been
>>
>> Suggestion:
>>
>> * @summary Verify that no
> For JEP 493-enabled builds there are no JMODs. Certain files come from the
> installed JDK image when a user creates a custom run-time from it. This is
> problematic for example for files that often come from a different package
> (e.g. `cacerts` file for Linux distro builds of OpenJDK package
On Wed, 9 Apr 2025 16:10:20 GMT, Severin Gehwolf wrote:
>> For JEP 493-enabled builds there are no JMODs. Certain files come from the
>> installed JDK image when a user creates a custom run-time from it. This is
>> problematic for example for files that often come from a different package
>> (
On Thu, 10 Apr 2025 09:03:36 GMT, Alan Bateman wrote:
>> It's very odd, but when I attempt this then the resource is not found. It
>> seems to fail on the module name verification. For example: `jlink --help |
>> tail -n2` shows as `disabled` for an enabled linkable runtime image.
>
> Without r
On Sat, 5 Apr 2025 04:49:03 GMT, Christoph Langer wrote:
>> Severin Gehwolf 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 four additional
>> c
On Tue, 8 Apr 2025 13:31:10 GMT, Severin Gehwolf wrote:
>> src/jdk.jlink/share/classes/jdk/tools/jlink/internal/LinkableRuntimeImage.java
>> line 71:
>>
>>> 69: private static InputStream getDiffInputStream(String module) throws
>>> IOException {
>>> 70: String resourceName = Strin
On Fri, 4 Apr 2025 07:55:20 GMT, Alan Bateman wrote:
>>> Part of me is concerned that the hidden option is a bit of an attractive
>>> nuisance. What would you think about just having a fixed list in a
>>> properties file in the repo, thus a resource in the jlink module. This
>>> would avoid th
On Wed, 9 Apr 2025 16:10:20 GMT, Severin Gehwolf wrote:
>> For JEP 493-enabled builds there are no JMODs. Certain files come from the
>> installed JDK image when a user creates a custom run-time from it. This is
>> problematic for example for files that often come from a different package
>> (
On Wed, 9 Apr 2025 11:42:31 GMT, Magnus Ihse Bursie wrote:
>> Sure. It's not really a properties file (which assumes `key=value`). How
>> about `upgrade_files_.conf`? Then the pattern could be
>> `upgrade_files_*.conf`. Thoughts?
>
> Yeah, my comment was meant more like "maybe you should turn i
On Wed, 9 Apr 2025 11:38:25 GMT, Severin Gehwolf wrote:
>> make/modules/jdk.jlink/Java.gmk line 28:
>>
>>> 26:
>>>
>>> 27:
>>> 28: COPY += upgrade_files_java.base
>>
>> Any chance you can give this file a differe
On Wed, 9 Apr 2025 10:36:03 GMT, Magnus Ihse Bursie wrote:
>> Severin Gehwolf has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Review v2
>
> make/modules/jdk.jlink/Java.gmk line 28:
>
>> 26:
>> ##
On Mon, 7 Apr 2025 13:35:57 GMT, Severin Gehwolf wrote:
>> For JEP 493-enabled builds there are no JMODs. Certain files come from the
>> installed JDK image when a user creates a custom run-time from it. This is
>> problematic for example for files that often come from a different package
>> (
On Mon, 7 Apr 2025 17:30:53 GMT, Alan Bateman wrote:
>> Severin Gehwolf has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Review v2
>
> src/jdk.jlink/share/classes/jdk/tools/jlink/internal/LinkableRuntimeImage.java
> line 71:
>
>> 69:
> For JEP 493-enabled builds there are no JMODs. Certain files come from the
> installed JDK image when a user creates a custom run-time from it. This is
> problematic for example for files that often come from a different package
> (e.g. `cacerts` file for Linux distro builds of OpenJDK package
On Sat, 5 Apr 2025 04:45:00 GMT, Christoph Langer wrote:
>> Severin Gehwolf 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 four additional
>> c
On Mon, 7 Apr 2025 12:14:28 GMT, Christoph Langer wrote:
>> Severin Gehwolf has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Review comments from Christoph
>
> test/jdk/tools/jlink/runtimeImage/UpgradeableFileCacertsTest.java line 42:
>
On Mon, 7 Apr 2025 12:11:51 GMT, Severin Gehwolf wrote:
>> For JEP 493-enabled builds there are no JMODs. Certain files come from the
>> installed JDK image when a user creates a custom run-time from it. This is
>> problematic for example for files that often come from a different package
>> (
> For JEP 493-enabled builds there are no JMODs. Certain files come from the
> installed JDK image when a user creates a custom run-time from it. This is
> problematic for example for files that often come from a different package
> (e.g. `cacerts` file for Linux distro builds of OpenJDK package
On Sat, 5 Apr 2025 04:49:03 GMT, Christoph Langer wrote:
> I see that you're actively on the upgradeable files. What about #24190?
Let's keep the discussion on #24190, please.
-
PR Comment: https://git.openjdk.org/jdk/pull/24388#issuecomment-2782507174
On Wed, 2 Apr 2025 18:39:57 GMT, Severin Gehwolf wrote:
> For JEP 493-enabled builds there are no JMODs. Certain files come from the
> installed JDK image when a user creates a custom run-time from it. This is
> problematic for example for files that often come from a different package
> (e.g.
On Thu, 3 Apr 2025 06:31:20 GMT, Alan Bateman wrote:
> What about changes to conf files, especially Java.security (for hardening TLS
> settings) - or at least pointing to a include?
You can still do that after creating the custom runtime as you do today when
linking using JMODs. The point of t
On Fri, 4 Apr 2025 15:22:10 GMT, Severin Gehwolf wrote:
>> For JEP 493-enabled builds there are no JMODs. Certain files come from the
>> installed JDK image when a user creates a custom run-time from it. This is
>> problematic for example for files that often come from a different package
>> (
On Thu, 3 Apr 2025 06:12:35 GMT, Bernd wrote:
> What about changes to conf files, especially Java.security (for hardening TLS
> settings) - or at least pointing to a include?
The opposite is where weaker or insecure algorithms are enabled, wouldn't want
that copied by jlink into another run-ti
On Fri, 4 Apr 2025 15:22:10 GMT, Severin Gehwolf wrote:
>> For JEP 493-enabled builds there are no JMODs. Certain files come from the
>> installed JDK image when a user creates a custom run-time from it. This is
>> problematic for example for files that often come from a different package
>> (
On Fri, 4 Apr 2025 07:55:20 GMT, Alan Bateman wrote:
>>> Part of me is concerned that the hidden option is a bit of an attractive
>>> nuisance. What would you think about just having a fixed list in a
>>> properties file in the repo, thus a resource in the jlink module. This
>>> would avoid th
> For JEP 493-enabled builds there are no JMODs. Certain files come from the
> installed JDK image when a user creates a custom run-time from it. This is
> problematic for example for files that often come from a different package
> (e.g. `cacerts` file for Linux distro builds of OpenJDK package
On Fri, 4 Apr 2025 07:55:20 GMT, Alan Bateman wrote:
> > I'm not entirely sure what you are suggesting. Is it keeping a list of
> > "upgradeable" files in a properties file. Files listed in that properties
> > file aren't checked for hash sums (i.e. even if it's not modified)? That
> > is, the
On Thu, 3 Apr 2025 10:25:28 GMT, Severin Gehwolf wrote:
> I'm not entirely sure what you are suggesting. Is it keeping a list of
> "upgradeable" files in a properties file. Files listed in that properties
> file aren't checked for hash sums (i.e. even if it's not modified)? That is,
> the expl
On Wed, 2 Apr 2025 18:39:57 GMT, Severin Gehwolf wrote:
> For JEP 493-enabled builds there are no JMODs. Certain files come from the
> installed JDK image when a user creates a custom run-time from it. This is
> problematic for example for files that often come from a different package
> (e.g.
On Thu, 3 Apr 2025 09:46:38 GMT, Alan Bateman wrote:
> Part of me is concerned that the hidden option is a bit of an attractive
> nuisance. What would you think about just having a fixed list in a properties
> file in the repo, thus a resource in the jlink module. This would avoid the
> list i
On Wed, 2 Apr 2025 18:39:57 GMT, Severin Gehwolf wrote:
> For JEP 493-enabled builds there are no JMODs. Certain files come from the
> installed JDK image when a user creates a custom run-time from it. This is
> problematic for example for files that often come from a different package
> (e.g.
34 matches
Mail list logo
