Hi Thomas,
What I've found helpful is the ability to amend or override the set of
modules contained in a modular runtime image via --module-path and
--upgrade-module-path.
If you use (Docker) containers to deploy your app, this can be employed
nicely to separate images with your app's dependencie
Hi Nicolai,
Funny, I was just exploring the related code the other day. If you are
interested, look for usage of
jdk.tools.jlink.internal.BasicImageWriter.MODULES_IMAGE_NAME, this will get
you to the code for writing the "modules" file.
--Gunnar
2018-01-08 21:06 GMT+01:00 Nicolai Parlog :
> H
On 10/01/2018 10:32, Gunnar Morling wrote:
Hi Thomas,
What I've found helpful is the ability to amend or override the set of
modules contained in a modular runtime image via --module-path and
--upgrade-module-path.
If you use (Docker) containers to deploy your app, this can be employed
nicely t
2018-01-10 16:28 GMT+01:00 Alan Bateman :
> On 10/01/2018 10:32, Gunnar Morling wrote:
>
>> Hi Thomas,
>>
>> What I've found helpful is the ability to amend or override the set of
>> modules contained in a modular runtime image via --module-path and
>> --upgrade-module-path.
>>
>> If you use (Dock
On 10/01/2018 17:39, Gunnar Morling wrote:
:
What exactly do you mean by "broken app module"? It was my
understanding that by applying that exclusion pattern, no trace
whatsoever of the app module would end up in the resulting runtime
image. If I run /bin/java --list-modules it's not shown in
