Evaluate -jpms-multi-release BND parameter

[ppkarwasz]

In our BND configuration we use the -jpms-multi-release configuration:

This instruction controls that if a JAR setup to be a multi-release jar the manifests & module-infos for each supported versions should be added.

However due to the order in which our only MRJs are built (the META-INF/versions folder are only added at the end), this BND instruction is a no-op. It only manifests together with #90, if the target directory is not clean.

Therefore we should:

• either remove the instruction,
• or fix the build of log4j-api and log4j-core so that the versioned classes are added before the bnd:bnd-process execution.

[ppkarwasz]

The idea behind MRJs coupled with JPMS is nice: newer version of Java might require less dependencies. The list of exported packages can also change depending on the Java version.

In our case, however, I think that the -jpms-multi-release option should be removed, since it does not offer much.

[vy]

@ppkarwasz, I presume the only subjects of this feature are -java9-suffixed modules in 2.x branch of the apache/logging-log4j2 repository, right?

If we totally remove -jpms-multi-release option, does it imply that we won't generate JPMS/OSGi module descriptors only for packages injected by -java9-suffixed modules?

[ppkarwasz]

Yes, log4j-api-java9 and log4j-core-java9 are the only modules affected by this setting.

If we remove the setting META-INF/versions/9/module-info.class and META-INF/versions/9/META-INF/MANIFEST.MF will not be generated. This should be completely fine since module-info.class and META-INF/MANIFEST.MF should be identical to those files.

Actually right now the versioned JPMS and OSGI descriptors are not being generated, since log4j-api-java9 and log4j-core-java9 are being unpacked only after bnd:bnd-process runs.