In #22684 It was suggested there might be another approach.
Comment From: 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.
Comment From: wilkinsona
How did the experimentation go, @dsyer?
Comment From: 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?
Comment From: 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.
Comment From: dsyer
The “feature layer” idea has nothing directly to do with native images, but I’m happy if Brian (or anyone) wants to comment.
Comment From: 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?
Comment From: 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.
Comment From: 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?
Comment From: 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.
Comment From: 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.
Comment From: snicoll
@dsyer what is the status of this issue?
Comment From: 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.