Use BND for both OSGI and JPMS

[ppkarwasz]

This PR is a work in progress and replaces #1815.

It replaces maven-bundle-plugin with bnd-maven-plugin, which:

• is maintained by the same project that releases the common backend BND, so our build system depends on one less project (Apache Felix),
• is released at each upgrade of the BND backend.

The introduction of JPMS support in BND allows us:

• to have real JPMS module descriptors that are verified to be complete at a bytecode level (even Class.forName calls are supported by BND).

To help in the review process, BND configurations for various modules will have their own PRs and this one will be complete when modifications to all modules will be accepted:

• log4j-1.2-api (Add BND configuration to log4j-1.2-api #1825),
• log4j-api (Add BND configuration for log4j-api #1820),
• log4j-api-test (Add BND configuration to Core dependents #1828),
• log4j-appserver (Add BND configuration to bridges #1827),
• log4j-cassandra (Add BND configuration to Core dependents #1828),
• log4j-core (Add BND configuration for log4j-core #1821),
• log4j-core-test (Add BND configuration to Core dependents #1828),
• log4j-couchdb (Add BND configuration to Core dependents #1828),
• log4j-docker (Add BND configuration to Core dependents #1828),
• log4j-flume-ng (Add BND configuration to Core dependents #1828),
• log4j-iostreams (Add BND configuration to bridges #1827),
• log4j-jcl (Add BND configuration to bridges #1827),
• log4j-jdbc-dbcp2 (Add BND configuration to Core dependents #1828),
• log4j-jpa (Add BND configuration to Core dependents #1828),
• log4j-jpl (Add BND configuration to bridges #1827),
• log4j-jul (Add BND configuration to bridges #1827),
• log4j-kubernetes (Add BND configuration to Core dependents #1828),
• log4j-layout-template-json (Add BND configuration to Core dependents #1828),
• logj4-layout-template-json-test (Add BND configuration to Core dependents #1828),
• log4j-mongodb3 (Add BND configuration to Core dependents #1828),
• log4j-mongodb4 (Add BND configuration to Core dependents #1828),
• log4j-slf4j2-impl (Add BND configuration to bridges #1827),
• logj4-slf4j-impl (Add BND configuration to bridges #1827),
• logj4-spring-boot (Add BND configuration to Core dependents #1828),
• logj4-spring-cloud-config-client (Add BND configuration to Core dependents #1828),
• log4j-taglib (Add BND configuration to Core dependents #1828),
• logj4-to-jul (Add BND configuration to bridges #1827),
• logj4-to-slf4j (Add BND configuration to bridges #1827),
• logj4-web (Add BND configuration to Core dependents #1828).

[ppkarwasz]

Using BND we still need to manually overwrite the detected (or undetected) module name of multi-release dependency JARs. Theoretically this was fixed in bndtools/bnd#5327, but I can't get it to work. The module name of MRJs with a module descriptor in their META-INF/versions/9 folder isn't

@HannesWell, do you know what am I missing?

[ppkarwasz]

Apparently the BND (partial) fix is only in the 7.1.0-SNAPSHOT branch.

[ppkarwasz]

Closes #1830.

[HannesWell]

Sorry for the late and after the fact reply. I just checked the following slf4j bundles in more detail and everything looks good and worked well in my testing in our two OSGi applications, from which one uses log4j-core as back-end and redirects every other API to it and the other one uses logback-classic and redirects all APIs to that:

• log4j-api
• log4j-core
• log4j-slf4j2-impl
• log4j-slf4j-impl
• log4j-to-slf4j (Especially the extended version range in Import-Package: org.slf4j;version="[1.7,3)",org.slf4j.spi;version="[1. 7,3)", ... is important)

I noted that for some bundles the symbolic name changed e.g. from o.a.l.log4j.slf4j2-impl to o.a.l.log4j.slf4j2.impl. In some cases this requires adjustments, e.g. if one requires the bundle instead of importing the contained packages. But since the former is discouraged anyways it shouldn't be a blocker and is IMHO fine.

If you want to keep the MANIFEST.MF a little bit cleaner you could remove the Private-Package, which is only for internal use of BND and could be removed with the instruction -removeheaders: Private-Package.

Thank you @ppkarwasz for this work!

[ppkarwasz]

@HannesWell,

That is great news, so I believe we have a green light to release 2.21.0, unless you have an idea what is going on in #1741.

Regarding the bundle names, we chose to prefer consistency (use bundle names that can be module names) over backward compatibility. If you can think of a place where bundle names are used (build scripts?), we can revert them to the original form.

Now we are just waiting for INFRA-25032.

[HannesWell]

That is great news, so I believe we have a green light to release 2.21.0, unless you have an idea what is going on in #1741.

From my point of view yes 🚀🙂

Regarding the bundle names, we chose to prefer consistency (use bundle names that can be module names) over backward compatibility. If you can think of a place where bundle names are used (build scripts?), we can revert them to the original form.

That's a reasonable choice. I'm know cases that depend on the bundle-name, for example if another Bundle requires a log4j bundle using OSGi's Require-Bundle (but that's discouraged/deprecated and as far as I know mainly used in the Eclipse world only. And since you provide good OSGi metadata, i.e. versioned packages, there is no reason to not used Import-Package instead, which only depends on the package name). Or if the bundles are part of an Eclipse Feature (which is basically a group of Bundles that form a 'feature' of an Eclipse Product like the IDE), but there names can be changed too and usually a feature once build is pinned to a specific version of the Bundle so there is no compatibility problem.
So IMHO the name change is fine, personally I find bundle-names with a dash a bit odd, but it should be mentioned in the release notes so that there is a change to simplify migration.