On Mon, 2026-01-26 at 13:30 +0000, Stefan Seifert wrote: > the actual root cause blocking the single POM apporach is the design > of the feature-launcher-maven-plugin > > when in the StartMojo [1] the feature launcher is started in a > separate process by calling the launcher script file - so the actual > launch of the aggregated feature happens completely separated from > the maven process, and thus has access only to artifacts available > any local or remote repository - but not artifacts from the current > maven build run which are not yet stored in the repository (because > the "install" phase has to be executed after the "integration-test" > phase). the correct solution would be to start the feature launcher > using java code and integrated as property maven dependency, and pass > over the file references attached to the current maven build. > > @robert: i think you implemented the current concept how the start > via feature-launcher-maven-plugin works. i assume there was a reason > to implement it that way, what do you think is the best approach to > solve this issue?
The reason was that I wanted to reuse the feature launcher infrastructure as much as possible. I vaguely remember that when trying to run multiple full-blown Sling instances in the same process I ran into conflicts with JMX MBeans which are effectively singletons. I agree that we should teach the Maven plug-in to use artifacts currently attached to the session. Do you think it's preferable to have a config option in the Maven plug-in that adds some attached artifacts to the feature model or that they are added to the feature model files as all bundles are? The implementation is mostly the same - we need teach the feature launcher to resolve artifacts from the local Maven build. This should be doable using a custom ArtifactProvider implementation that looks in a configured target directory and matches Maven coordinates based on the discovered metadata. > > i don't think workarounds like uploading the bundles from the current > builds in other ways after the launcher is started e.g. like > teleporter is doing it is the right way for those bundles. from a > maven plugin you expect it behaves as usual in the maven ecosystem, > so it should have access to the artifacts attached to the current > build run as well. +1 Robert > > stefan > > [1] > https://github.com/apache/sling-feature-launcher-maven-plugin/blob/49a92400e4d14819646e013c726fe5821db86d21/src/main/java/org/apache/sling/maven/feature/launcher/StartMojo.java#L148-L360 >
