We use `bnd`, in particular, `bnd-maven-plugin` <https://github.com/bndtools/bnd/blob/master/maven-plugins/bnd-maven-plugin> to programmatically declare JPMS/OSGi module exports and service providers. Effectively, it generates `module-info.class`, `META-INF/services`, and (OSGi-related) `MANIFEST.MF` files. We also enhance this experience with `bnd-baseline-maven-plugin` <https://github.com/bndtools/bnd/tree/master/maven-plugins/bnd-baseline-maven-plugin> to enforce API compatibility between versions.
I really like this! We use `@Export`, `@Version`, `@ServiceConsumer`, `@ServiceProvider`, etc. annotations in the code and `bnd` takes care of the rest. Though in the last couple of months, I have noticed several nuances that started to make me consider pros/cons of this convenience. *Good: Programmatic configuration* No need to manually populate `module-info.java`, `META-INF/services`, `MANIFEST.MF` files. Everything is in the code. Great! *Bad: Programmatic configuration is not enough* We still need to tweak the generated `module-info.class` in several places. We have hundreds of lines of manual treatment: you can simply search for `<bnd` text in `pom.xml` files in `2.x` branch. *Good: Absence of `module-info.java`* We use `bnd:jar` goal to populate `module-info.class` and attach it to the generated JAR. That is, there are no `module-info.java` and `module-info.class` files anywhere in the `target` folder. This makes life with IDEs a lot easier. IDEs simply work [not really, but I will talk about that later], since they think there are no JPMS descriptors to deal with. *Bad: IDEs cannot discover services* Since `META-INF/services` is only available in the generated JAR, IDEs are not able to discover services. *Bad: `bnd:jar` attaches the generated files always at the end* Currently, if the `package` phase has multiple plugin executions, `bnd:jar` 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` and effectively missing all `bnd:jar`-generated files. *Bad: Switching to `bnd:bnd-process` is not a cure either* Piotr and I have been thinking about switching from `bnd:jar` to `bnd:bnd-process`, since the latter will output everything generated to the `target` folder. Though this is not a cure without any side effects either. <https://github.com/apache/logging-parent/issues/69#issuecomment-1845373576> *Bad: Mismatch with the community and ecosystem* AFAIK, almost no major project uses `bnd-maven-plugin`. (This is more of a gut feeling, I haven't done an empirical study on this.) We are alone with our problems and others' solutions (catered against mainstream which hand-craft `module-info.java`, etc. files) don't work for us. *What now?* `bnd-maven-plugin` is a great tool with an active community. It delivers its promises perfectly. Though the surrounding ecosystem (IDEs, not-JPMS'ed-yet libraries, etc.) doesn't always play nice with it and eventually we end up tweaking it, *a lot*. I am sitting on the fence whether it is a curse or a blessing. I will appreciate your thoughts on the matter.
