Currently we are using the jar goal of the BND plugin to generate:

• an OSGi manifest,
• a JPMS module descriptor,
• a set of META-INF/services files.

All this happens in the package phase of the Maven Lifecycle and is therefore available only for integration tests.

We should consider using the bnd-process goal, which produces the same files in the process-classes phase and makes them available to unit tests.

Such a change would require:

• changing the BND goal from jar to bnd-process. Since the bnd-process goal does not require <extension>true</extension>, it would also solve Skip bnd-maven-plugin configuration when bnd.skip is present #34,
• check the configuration of the Maven Jar Plugin that will automatically activate,
• check the configuration of the Maven Surefire Plugin: IIRC the plugin detects the presence of module-info.class file (not a module-info.java file as documented), so we might need to use <useModulePath>false</useModulePath,
• checking how IDEs react to the presence of module-info.class and if they can integrate BND as part of their build (Eclipse M2E can integrate Maven plugins in its build, I am not sure about IDEA).

Remark: switching from jar to bnd-process might have another beneficial effect. Currently if the package phase has multiple plugin executions, BND removes the Maven Jar plugin execution and adds its own at the end (not sure if that is fixable). E.g.: adding spring-boot:repackage in a naive way, causes spring-boot:repackage to be executed before bnd:jar.