Provide API/hook for enhancing fat jar in build plugins

[dsyer]

In #22684 It was suggested there might be another approach.

[wilkinsona]

Rather than us making changes to the Maven plugin to enable your experimentation, I think you'd be better switching to Gradle for the time being. This should give you all the flexibility you want (and then some, probably). Once the experimentation has settled down and we have a good idea of the approach that we want users to take, we can then look at what it will take to make it possible to do with Maven what you're doing with Gradle. Depending on how complex it is, we could also look at providing some helper tasks and/or methods to streamline the Gradle side of things as well.

[wilkinsona]

How did the experimentation go, @dsyer?

[dsyer]

I'm not really qualified to experiment on anything with Gradle, so I didn't take this any further. The original impetus was native image enhancements, but I'm not sure we need that any more. We did also talk about some configuration hooks for the build plugin to add additional "features" (i.e. a new dependency and all its transitives that are not already in another, lower, layer). I'd still like to do that, and I have some experiments that show how to do it with a custom buildpack. Do we have another issue for that, or should we co-opt this one?

[wilkinsona]

Thanks for the update. I'll defer to @bclozel on how to handle Spring Native-related issues as he's leading that effort on the Boot side. I'm not sure if we want them here or in an experimental project while we figure out what shape things are going to take.

[dsyer]

The “feature layer” idea has nothing directly to do with native images, but I’m happy if Brian (or anyone) wants to comment.

[wilkinsona]

Ah, sorry. I read "build plugin" as being a plugin that was related to the building of native images not Boot's general Maven and Gradle build plugins.

What's the benefit of configuring a feature layer via custom Maven or Gradle support vs adding it to the application's dependencies directly?

[dsyer]

If you add it to the dependencies directly it's always on the classpath. I'm more interested in layers that you can activate at dev time or in different environments selectively.

[wilkinsona]

I don't think I understand the benefit of them going into a layer. Perhaps there's something that makes it easy to include or exclude a layer when building an image without changing anything else?

[dsyer]

It doesn't have to be a layer. But a separate directory would help to include/exclude them wouldn't it, and then a layer is a natural choice? Once you have them in a directory you want to create additional "process types" (in buildpack terms) that include or exclude them and can be selected by the container/pod entrypoint/command.

[philwebb]

@bclozel and @snicoll are working on the AOT efforts so I think we should close this one for now. I suspect we may need to rethink the way that the repackager works in general but it feels a bit early to try and do it in Boot at the moment.

[snicoll]

@dsyer what is the status of this issue?

[dsyer]

It’s still a valid use case, and I never saw a good way to implement it with existing Spring Boot tools. I’d have to write a messy Dockerfile probably, or a custom buildpack, like I did back when I opened the ticket.