Add ability to read custom layers.xml from classpath

[juanpablo-santos]

Currently, it is possible to provide a custom layers.xml file to the maven plugin, but it seems to be read with a FileInputStream, so only file references are understood. It would be nice if the file could also be read from classpath (i.e., via plugin dependency).

[philwebb]

It doesn't appear to be that common for Maven plugins to offer file and classpath resolution on the same property so I'm not sure what format we'd use to support this. The obvious solution is to use Spring's resource abstraction and support the classpath: prefix, but we don't really want a Spring dependency in out Maven plugin. I wonder if a more specific extension point would be better? For example we have org.springframework.boot.loader.tools.LayoutFactory to support custom layouts.

@juanpablo-santos What's driving this request? Have you often found you need use the same layers configuration in multiple apps?

[snicoll]

Looking at the maven assembly plugin it has this notion of "named" descriptor you can put on the classpath and reuse, see https://maven.apache.org/plugins/maven-assembly-plugin/examples/sharing-descriptors.html

[juanpablo-santos]

Hi @philwebb, @snicoll thanks for the insights,

we have two use cases for this:

• maven multimodule applications: we wish to put on a separate layer the other project jars; they change with every release, so the dependencies layer doesn't get reused at all for our applications.
• corporate builds: we do get a subset of dependencies mandated by a corporate pom, which change less frequently than the project builds, but do change more frequently than the "main" dependencies (spring-boot et al)

having the option to instruct the spring-boot maven plugin to take a file from classpath would ease the reuse of a shared layers.xml file, without invoking other plugins, which wastes a small amount of time (grab from the repo, unpack file) and adds some configuration to one of the built modules. Our workaround was to use the remote-resources plugin, which is similar to the shared descriptor from the assembly plugin, but we were hoping to avoid the need of invoking yet another plugin.

Either having a separate argument, understood only if the configuration parameter isn't set, or look into getClass().getClassLoader().getResource(..) if the file isn't found would work for us, and would be the cleanest way for our use cases.

Regarding the LayoutFactory that would also certainly work for us, we will have a look at it; is there any sample to look at how to interact with the layers.idx file? is that needed? I see some references to it on the DefaultLayoutFactory but I'm not sure if it is just to tell where it is located or if any other interaction with it should be needed.

[mefernandez]

👍 We also have a multi-module Maven project. We need a separate layer for our own dependencies to reduce Docker image size. We would love to provide a default layers.xml for this in some common dependency, otherwise we would need to include the same layers.xml for every project, which is cumbersome.