Update a runtime image

[Thomas Brand]

Hello, I have a question related to jlink.

In a scenario where a runnable image created with jlink is installed, and
it should be updated, what are good strategies for doing this?

I think if an update will introduce new dependencies this will be
different to updates that are known to be satisfied with what is already
in the image.

The idea is to 'ship' just a small sort of diff / replacement part that
can be applied to the 'old' image to become 'new'.

Thanks for any insights, and happy silvester / new year!
Thomas

[Alan Bateman]

Post by Thomas Brand
Hello, I have a question related to jlink.
In a scenario where a runnable image created with jlink is installed, and
it should be updated, what are good strategies for doing this?
I think if an update will introduce new dependencies this will be
different to updates that are known to be satisfied with what is already
in the image.
The idea is to 'ship' just a small sort of diff / replacement part that
can be applied to the 'old' image to become 'new'.

The jlink tool always generates a new run-time image, there is no
support at this time to install additional modules into a run-time image.

-Alan.

[Remi Forax]

jlink is not a distribution tool,
you need to use a tool on top of jlink, in the past, i've used the rpm format for that.

We have stopped to distribute deltas when we have moved to docker that as far as i know as no concept of incremental update.

Rémi

----- Mail original -----

Envoyé: Dimanche 31 Décembre 2017 16:55:37
Objet: Re: Update a runtime image

Post by Thomas Brand
Hello, I have a question related to jlink.
In a scenario where a runnable image created with jlink is installed, and
it should be updated, what are good strategies for doing this?
I think if an update will introduce new dependencies this will be
different to updates that are known to be satisfied with what is already
in the image.
The idea is to 'ship' just a small sort of diff / replacement part that
can be applied to the 'old' image to become 'new'.

The jlink tool always generates a new run-time image, there is no
support at this time to install additional modules into a run-time image.
-Alan.

[Thomas Brand]

jlink is not a distribution tool, you need to use a tool on top of jlink,
in the past, i've used the rpm format for that.
We have stopped to distribute deltas when we have moved to docker that as
far as i know as no concept of incremental update.
Rémi
----- Mail original -----

Envoyé: Dimanche 31 Décembre 2017 16:55:37
Objet: Re: Update a runtime image

Post by Thomas Brand
Hello, I have a question related to jlink.
In a scenario where a runnable image created with jlink is installed,
and it should be updated, what are good strategies for doing this?
I think if an update will introduce new dependencies this will be
different to updates that are known to be satisfied with what is
already in the image.
The idea is to 'ship' just a small sort of diff / replacement part
that can be applied to the 'old' image to become 'new'.

The jlink tool always generates a new run-time image, there is no
support at this time to install additional modules into a run-time image.
-Alan.

Thanks for the facts & suggestions!
Greetings

[Gunnar Morling]

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 dependencies (as a modular
runtime image) and a very thin image with your app itself. Unless your
dependencies change, only the latter one needs to be re-built and
distributed. The "exclude-resources" plug-in comes in handy for omitting
your app from the modular runtime image. I've written about it here:
https://github.com/moditect/moditect/wiki/Creating-dependency-images.

--Gunnar

Post by Thomas Brand

jlink is not a distribution tool, you need to use a tool on top of jlink,
in the past, i've used the rpm format for that.
We have stopped to distribute deltas when we have moved to docker that as
far as i know as no concept of incremental update.
Rémi
----- Mail original -----

Envoyé: Dimanche 31 Décembre 2017 16:55:37
Objet: Re: Update a runtime image

Post by Thomas Brand
Hello, I have a question related to jlink.
In a scenario where a runnable image created with jlink is installed,
and it should be updated, what are good strategies for doing this?
I think if an update will introduce new dependencies this will be
different to updates that are known to be satisfied with what is
already in the image.
The idea is to 'ship' just a small sort of diff / replacement part
that can be applied to the 'old' image to become 'new'.

The jlink tool always generates a new run-time image, there is no
support at this time to install additional modules into a run-time image.
-Alan.

Thanks for the facts & suggestions!
Greetings

[Alan Bateman]

Post by Gunnar Morling
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 dependencies (as a modular
runtime image) and a very thin image with your app itself. Unless your
dependencies change, only the latter one needs to be re-built and
distributed. The "exclude-resources" plug-in comes in handy for omitting
https://github.com/moditect/moditect/wiki/Creating-dependency-images.

If I understand this correctly then the app module is linked into the
run-time image to force its dependences to be linked in. It might be
saner to just get its list of `requires` and specify that list to jlink.
That way the app module can be specified on the module path (you are
otherwise forced to use the upgrade module path to avoid the broken app
module in the run-time image).

-Alan

[Gunnar Morling]

Post by Gunnar Morling
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 dependencies (as a modular
runtime image) and a very thin image with your app itself. Unless your
dependencies change, only the latter one needs to be re-built and
distributed. The "exclude-resources" plug-in comes in handy for omitting
https://github.com/moditect/moditect/wiki/Creating-dependency-images.
If I understand this correctly then the app module is linked into the

run-time image to force its dependences to be linked in. It might be saner
to just get its list of `requires` and specify that list to jlink. That way
the app module can be specified on the module path (you are otherwise
forced to use the upgrade module path to avoid the broken app module in the
run-time image).

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
<IMAGE>/bin/java --list-modules it's not shown in the image's module list,
and things works for me when I add it via --module-path.

But either what you suggest might be cleaner indeed.

-Alan

[Alan Bateman]

Post by Gunnar Morling
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 <IMAGE>/bin/java --list-modules it's not shown in the
image's module list, and things works for me when I add it via
--module-path.

I think there may be a bug here. The exclude-resources plugin was
created for selectively removing resources, it was never mean to be able
to remove a module completely.

-Alan.