apache/logging-parent

Parent project internally used in Maven-based projects of the Apache Logging Services

Parent project internally used in Maven-based projects of the Apache Logging Services projects. See the project website for further information.

logging-parent's Issues

Clean up after `apache:apache:32` upgrade

This task lists the clean up tasks to perform after the release of apache:apache version 32:

• remove the version override for org.apache.rat:apache-rat-plugin.

Improve `merge-dependabot-reusable.yaml`

• Share the ticket ID in the commit message
• Share commit ID in the comment added to the ticket

Inherited `project.build.outputTimestamp` causes `artifact:compare` errors

artifact:compare does not like inherited project.build.outputTimestamps:

...
- artifact:3.4.1:compare (default-cli) @ log4j-core-java9 ---
[ERROR] project.build.outputTimestamp property should not be inherited but defined in parent POM from reactor /home/vy/Projects/logging-dist-dev/log4j/src/target/.flattened-pom.xml
...

RMs can manually add/update them, though this would be yet another manual step in our ever growing release instructions manual. Ideally, CI should set this value prior to releasing.

Clean up Apache RAT configuration

Due to the RAT-355 enhancement, Apache Rat 0.16 is now able to implicitly ignore most files ignored by Git.

This allows us to clean up the configuration from all the files that are also in a typical .gitignore.

Upgrade BND plugin to version `7.0.0`

BND version 7.0.0 introduces support for multi-release JARs (cf. release notes).

This feature is important for us since many of our JPMS dependencies are MRJs that contain a module descriptor only in their Java 9 version. Without MRJ support BND can not detect the real module name of these dependencies and falls-back to a filename-based one: e.g. slf4j-api version 2.x is recognized as slf4j-api instead of the actual module name org.slf4j (cf. apache/logging-log4j2#1983).

The only catch is: BND 7.x has a baseline of Java 17, so all our builds must run using this JDK. apache/logging-log4j2#1851 might be a blocker for this upgrade.

Upload build and reproducibility problems to Github

The reusable build should:

1. Upload Surefire reports and the target/logs folder if a build fails,
2. Upload the artifact comparison failure if the "Reproducibility" step fails.

Clean-up `target/classes` directory before compilation

The javac compiler starts behaving differently if it finds module-info.class file from a previous compilation in the target directory: it tries to resolve the modules, but it fails since the module jars are on the classpath, not the modulepath:

error: module not found: org.apache.logging.log4j

Therefore we need to use a clean execution before each compile execution that will delete that file.

Project is released with lazy-consensus, though `generate-email.sh` doesn't reflect this

Skip `bnd-maven-plugin` configuration when `bnd.skip` is present

When bnd.skip is present, the bnd-maven-plugin configuration still kicks in and causes a

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-install-plugin:3.1.1:install (default-install) on project log4j-transform-maven-shade-plugin-extensions: The packaging for this project did not assign a file to the build artifact

failure.

Ban wildcard imports

An inconsistent usage of wildcard imports causes problems when we compare multiple release branches.

Since our old Style Guide bans their usage too, we should add a style check that fails the build in their presence. We can use the Maven Enforcer Rule skuzzle/restrict-imports-enforcer-rule for example.

Switch from `bnd:jar` to `bnd:bnd-process`

Currently we are using the jar goal of the BND plugin to generate:

• an OSGi manifest,
• a JPMS module descriptor,
• a set of META-INF/services files.

All this happens in the package phase of the Maven Lifecycle and is therefore available only for integration tests.

We should consider using the bnd-process goal, which produces the same files in the process-classes phase and makes them available to unit tests.

Such a change would require:

• changing the BND goal from jar to bnd-process. Since the bnd-process goal does not require <extension>true</extension>, it would also solve #34,
• check the configuration of the Maven Jar Plugin that will automatically activate,
• check the configuration of the Maven Surefire Plugin: IIRC the plugin detects the presence of module-info.class file (not a module-info.java file as documented), so we might need to use <useModulePath>false</useModulePath,
• checking how IDEs react to the presence of module-info.class and if they can integrate BND as part of their build (Eclipse M2E can integrate Maven plugins in its build, I am not sure about IDEA).

Remark: switching from jar to bnd-process might have another beneficial effect. Currently if the package phase has multiple plugin executions, BND 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.

Evaluate `-jpms-multi-release` BND parameter

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.

`distribution` profile cannot process symlinked directories

When there are symbolic-linked directories in the Git-tracked files, distribution profile fails while creating src.zip.

Add JSpecify annotations to defaults

As noted in https://issues.apache.org/jira/browse/LOG4J2-1477, JSpecify is the project specifying the one true nullability annotation standard. I experimented with creating copies of those annotations that use the JSR 305 nullability annotations to implement it, but it seems like it'd be easier to just use these annotations directly since they're only required at compile time. The use of these annotations would supersede any use of the old JSR annotations.

[Staging] website is missing in `generate-email.sh`

Improve overwritability of BND configuration

Right now logging-parent provides two knobs to overwrite BND's generated OSGi package imports and JPMS module requirements:

• <bnd-extra-package-options> allows to overwrite OSGi Import-Package statements,
• <bnd-extra-module-options> allows to overwrite JPMS module requirements.

However these macros appear last in the definition of -jpms-module-info-options, which prevents child POMs from redefining the keys (like org.apache.logging.log4j) that are already defined in logging-parent.

Keep parent in `flatten-bom` configuration

flatten-bom configuration of flatten-maven-plugin doesn't keep the parent. This causes build failures for artifacts whose dependencies need to be resolved at runtime. Consider the following problem experienced in log4j-transform-maven-plugin:

1. log4j-transform-parent depends on log4j-transform-bom
2. log4j-transform-bom depends on logging-parent
3. logging-parent contains dependencyManagement, etc. that are used by log4j-transform-maven-plugin
4. Dependencies of log4j-transform-maven-plugin et al. is resolved at runtime
5. Though at runtime, the deployed -bom is used, which is flattened and hence doesn't have a parent!
6. Hence, at runtime, all logging-parent logic is lost

To avoid this, flatten-bom configuration should better keep the parent using <parent>keep</parent> in pomElements block.