Hi Volkan, I have supplied a PR to generate the service descriptors before Unit tests, but keep the module-info.class only in the JAR:
https://github.com/apache/logging-parent/pull/75 On Thu, 7 Dec 2023 at 15:41, Volkan Yazıcı <vol...@yazi.ci> wrote: > *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. Most of the additional configuration is due to: 1. BND 6.x does not support multi-release JARs, so the module names of **modern** dependencies are wrong. It is fixed in BND 7.x (requires JDK 17). 2. **Old** dependencies do not even have an `Automatic-Module-Name` and BND 6.x uses a different algorithm than Modulefinder#of to generate file-base module names. Peter Kriens fixed it in: https://github.com/bndtools/bnd/issues/5792 which is due to be published in version 7.1.x. There is only one problem remaining: old dependencies **should** only be added as `static` (optional). We still need a manual override for that, but I don't think anybody will run `log4j-cassandra` on the module path. 3. Optional dependencies: we need to explicitly mark some imported packages as optional. This is an explicit decision of the BND Team: https://github.com/bndtools/bnd/issues/2713 > *Bad: IDEs cannot discover services* > > Since `META-INF/services` is only available in the generated JAR, IDEs are > not able to discover services. This is fixed in my PR. > *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. That might be fixable with a PR. I could look into that. Piotr
