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? 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. 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
