Note that there is also the Maven moditect plugin but I don't know if it deals with OSGi which brings up the issue of how much we should care about OSGi (I don't know).
Gary On Thu, Dec 7, 2023, 9:41 AM Volkan Yazıcı <vol...@yazi.ci> wrote: > 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. >
