With this change the OSGi metadata of all remaining slf4j modules are generated using the maven-bundle-plugin.
This makes all remaining MANIFEST.MF files obsolete and they are therefore removed. Then sfl4j only has one source for OSGi metadata: the configuration of the maven-bundle-plugin. This simplifies the understanding how the metadata are crafted and maintenance on the long run, as requested in https://github.com/qos-ch/slf4j/pull/331#issuecomment-1472395543 and noted in SLF4J-583.
This also re-adds metadata that where accidentally removed in 2.0.6 and thus fixes SLF4J-578.
Additionally it improves the metadata by adding more use-clauses to more Export-Package entries.
@ceki can you please review this or let me know if you want to have this split up? I know you prefer smaller steps, but I didn't wanted to create one PR for each slf4j module and therefore made a bigger change. Nevertheless the single changes are now simpler compared to other PRs.
The PR is build in two steps. The first commit is dedicated to restore missing metadata and to remove entries from the manifest that are already generated by the m-bundle-plugin and are therefore duplicates. This already allowed to remove some Manifests entirely.
The second commit then replaces all remaining manifests by a corresponding configuration of the maven-bundle-plugin, so that no OSGi metadata are crafted from that. In order to simplify the generation of the OSGi Service Loader Mediator headers I created a profile that is activated by the existence of the file src/main/resources/META-INF/services/org.slf4j.spi.SLF4JServiceProvider and adds the corresponding manifest headers. The properties in the header are filled with values from the corresponding project.
Please let me know if you want a change or something is not clear.
This is a follow-up of https://github.com/qos-ch/slf4j/pull/324 and the reduced version of https://github.com/qos-ch/slf4j/pull/327, that has not been covered in https://github.com/qos-ch/slf4j/pull/330.
With this change the OSGi metadata of all remaining slf4j modules are generated using the maven-bundle-plugin. This makes all remaining MANIFEST.MF files obsolete and they are therefore removed. Then sfl4j only has one source for OSGi metadata: the configuration of the maven-bundle-plugin. This simplifies the understanding how the metadata are crafted and maintenance on the long run, as requested in https://github.com/qos-ch/slf4j/pull/331#issuecomment-1472395543 and noted in SLF4J-583.
This also re-adds metadata that where accidentally removed in 2.0.6 and thus fixes SLF4J-578. Additionally it improves the metadata by adding more use-clauses to more Export-Package entries.
@ceki can you please review this or let me know if you want to have this split up? I know you prefer smaller steps, but I didn't wanted to create one PR for each slf4j module and therefore made a bigger change. Nevertheless the single changes are now simpler compared to other PRs. The PR is build in two steps. The first commit is dedicated to restore missing metadata and to remove entries from the manifest that are already generated by the m-bundle-plugin and are therefore duplicates. This already allowed to remove some Manifests entirely. The second commit then replaces all remaining manifests by a corresponding configuration of the maven-bundle-plugin, so that no OSGi metadata are crafted from that. In order to simplify the generation of the OSGi Service Loader Mediator headers I created a profile that is activated by the existence of the file
src/main/resources/META-INF/services/org.slf4j.spi.SLF4JServiceProvider
and adds the corresponding manifest headers. The properties in the header are filled with values from the corresponding project.Please let me know if you want a change or something is not clear.