Repository navigation
Evaluate -jpms-multi-release BND parameter #93
Description
Activity
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-releaseoption should be removed, since it does not offer much.@ppkarwasz, I presume the only subjects of this feature are
-java9-suffixed modules in2.xbranch of the apache/logging-log4j2 repository, right?If we totally remove
-jpms-multi-releaseoption, does it imply that we won't generate JPMS/OSGi module descriptors only for packages injected by-java9-suffixed modules?Yes,
log4j-api-java9andlog4j-core-java9are the only modules affected by this setting.If we remove the setting
META-INF/versions/9/module-info.classandMETA-INF/versions/9/META-INF/MANIFEST.MFwill not be generated. This should be completely fine sincemodule-info.classandMETA-INF/MANIFEST.MFshould be identical to those files.Actually right now the versioned JPMS and OSGI descriptors are not being generated, since
log4j-api-java9andlog4j-core-java9are being unpacked only afterbnd:bnd-processruns.
In our BND configuration we use the
-jpms-multi-releaseconfiguration:However due to the order in which our only MRJs are built (the
META-INF/versionsfolder 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:
log4j-apiandlog4j-coreso that the versioned classes are added before thebnd:bnd-processexecution.