On Fri, 13 Dec 2024 16:15:03 GMT, Severin Gehwolf wrote:
> > This method, in turn, calls `JLinkBundlerHelper.getDefaultModules()` which
> > uses `Configuration.empty().resolveAndBind()` which performs the service
> > binding.
>
> So it appears using `Configuration.empty().resolve()` instead wo
On Fri, 13 Dec 2024 16:14:13 GMT, Severin Gehwolf wrote:
> This method, in turn, calls `JLinkBundlerHelper.getDefaultModules()` which
> uses `Configuration.empty().resolveAndBind()` which performs the service
> binding.
So it appears using `Configuration.empty().resolve()` instead would fix th
On Tue, 10 Dec 2024 17:14:32 GMT, Mandy Chung wrote:
> Can you clarify how `jdk.jpackage` and `jdk.jlink` are included in
> `ALL-DEFAULT`? They do not have unqualified exports and hence they are not in
> the default set of root modules. They are service providers of
> `ToolProvider`. However,
On Tue, 10 Dec 2024 16:20:42 GMT, Alan Bateman wrote:
> That would only make sense if jpackage can work without jlink
It can. It invokes the jlink only if external runtime is not supplied, which is
likely the default setup in most cases. jlink dependency is optional but
required in common use
On Mon, 9 Dec 2024 12:57:22 GMT, Severin Gehwolf wrote:
> Please review these changes to jpackage in light of [JEP
> 493](https://openjdk.org/jeps/493). When this feature is enabled, then some
> of the `jpackage` tests fail. The failures fall into the following categories:
>
> - `ALL-DEFAULT`
On Mon, 9 Dec 2024 12:57:22 GMT, Severin Gehwolf wrote:
> Please review these changes to jpackage in light of [JEP
> 493](https://openjdk.org/jeps/493). When this feature is enabled, then some
> of the `jpackage` tests fail. The failures fall into the following categories:
>
> - `ALL-DEFAULT`
On Tue, 10 Dec 2024 16:07:00 GMT, Alexey Semenyuk wrote:
> Will changing `requires jdk.jlink;` to `requires static jdk.jlink;` let
> include `jdk.jpackage` without `jdk.jlink`?
That would only make sense if jpackage can work without jlink, meaning all the
options for creating a run-time image
On Mon, 9 Dec 2024 22:04:38 GMT, Alexey Semenyuk wrote:
> I don't think it is necessary to exclude jdk.jpackage from the `ALL-DEFAULT`
> though if jdk.jlink module should be excluded. As I commented earlier,
> jdk.jpackage is functional without the jdk.jlink.
You cannot include `jdk.jpackage`
On Mon, 9 Dec 2024 12:57:22 GMT, Severin Gehwolf wrote:
> Please review these changes to jpackage in light of [JEP
> 493](https://openjdk.org/jeps/493). When this feature is enabled, then some
> of the `jpackage` tests fail. The failures fall into the following categories:
>
> - `ALL-DEFAULT`
On Mon, 9 Dec 2024 19:16:59 GMT, Alexey Semenyuk wrote:
> > You can create custom runtimes from it, just not include jdk.jlink in the
> > output image that you generate.
>
> I understand "the output image" will not have jdk.jlink part. Does this mean
> there will be no "jlink" tool in "the out
On Mon, 9 Dec 2024 12:57:22 GMT, Severin Gehwolf wrote:
> Please review these changes to jpackage in light of [JEP
> 493](https://openjdk.org/jeps/493). When this feature is enabled, then some
> of the `jpackage` tests fail. The failures fall into the following categories:
>
> - `ALL-DEFAULT`
On Mon, 9 Dec 2024 19:00:28 GMT, Mandy Chung wrote:
> The jpackage tool packages a Java application into a platform-specific
> package with all necessary dependencies
It can package a runtime, not only an app in the native package.
> I hardly see how ALL-DEFAULT and ALL-MODULE-PATH tokens are
On Mon, 9 Dec 2024 12:57:22 GMT, Severin Gehwolf wrote:
> Please review these changes to jpackage in light of [JEP
> 493](https://openjdk.org/jeps/493). When this feature is enabled, then some
> of the `jpackage` tests fail. The failures fall into the following categories:
>
> - `ALL-DEFAULT`
On Mon, 9 Dec 2024 18:26:13 GMT, Alexey Semenyuk wrote:
> > The question is how useful do users see the need to have jdk.jlink part
> > when they don't use the --runtime-image option and jpackage
>
> If they don't use `--runtime-image` option, and jdk.jlink module is not
> available there is n
On Mon, 9 Dec 2024 18:15:32 GMT, Severin Gehwolf wrote:
> Technically it could be part, but it's just not allowed (yet) by policy
Maybe relax the policy given it causes inconvenience already? :-)
-
PR Comment: https://git.openjdk.org/jdk/pull/22644#issuecomment-2529021849
On Mon, 9 Dec 2024 18:15:24 GMT, Alexey Semenyuk wrote:
>> @alexeysemenyukoracle Do you mean it would be OK to re-define `ALL-DEFAULT`
>> to not include `jdk.jlink` for runtime images? Would that be OK in general
>> for `jpackage`?
>
> I meant the use of `jdk.internal.module.ModulePath` can be
On Mon, 9 Dec 2024 17:43:45 GMT, Severin Gehwolf wrote:
>>> If we change how jpackage defines ALL-DEFAULT we could reduce it
>>
>> I agree. jpackage can define ` ALL-DEFAULT` using public API, no need to use
>> internal API.
>
> @alexeysemenyukoracle Do you mean it would be OK to re-define `AL
On Mon, 9 Dec 2024 18:00:31 GMT, Alexey Semenyuk wrote:
> > The proposal is to not include jdk.jlink and jdk.jpackage by default on a
> > JDK build with JEP 493 enabled
>
> jpackage can use external runtime through `--runtime-image` cli option and
> not invoke jlink.
>
> Would you consider ad
On Mon, 9 Dec 2024 12:57:22 GMT, Severin Gehwolf wrote:
> The proposal is to not include jdk.jlink and jdk.jpackage by default on a JDK
> build with JEP 493 enabled
jpackage can use external runtime through `--runtime-image` cli option and not
invoke jlink.
Would you consider adding an error
On Mon, 9 Dec 2024 17:31:37 GMT, Alexey Semenyuk wrote:
>> Yes, I feared this might be a concern. If we change how `jpackage` defines
>> `ALL-DEFAULT` we could reduce it. The remaining use would be the case for
>> issuing a warning for missing `jmods` directory, for which it's probably not
>>
On Mon, 9 Dec 2024 12:57:22 GMT, Severin Gehwolf wrote:
> Please review these changes to jpackage in light of [JEP
> 493](https://openjdk.org/jeps/493). When this feature is enabled, then some
> of the `jpackage` tests fail. The failures fall into the following categories:
>
> - `ALL-DEFAULT`
On Mon, 9 Dec 2024 13:30:59 GMT, Severin Gehwolf wrote:
> If we change how jpackage defines ALL-DEFAULT we could reduce it
I agree. jpackage can define ` ALL-DEFAULT` using public API, no need to use
internal API.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/22644#discus
On Mon, 9 Dec 2024 12:57:22 GMT, Severin Gehwolf wrote:
> Please review these changes to jpackage in light of [JEP
> 493](https://openjdk.org/jeps/493). When this feature is enabled, then some
> of the `jpackage` tests fail. The failures fall into the following categories:
>
> - `ALL-DEFAULT`
On Mon, 9 Dec 2024 13:21:31 GMT, Alan Bateman wrote:
>> Please review these changes to jpackage in light of [JEP
>> 493](https://openjdk.org/jeps/493). When this feature is enabled, then some
>> of the `jpackage` tests fail. The failures fall into the following
>> categories:
>>
>> - `ALL-DEF
Please review these changes to jpackage in light of [JEP
493](https://openjdk.org/jeps/493). When this feature is enabled, then some of
the `jpackage` tests fail. The failures fall into the following categories:
- `ALL-DEFAULT` notion from `jpackage` which includes all modules that export
an AP
25 matches
Mail list logo
