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

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.

Add profile to generate a coverage report

While we don't check test coverage very often, it is sometimes useful to generate a coverage report, when evaluating PRs.

Retain `project.build.outputTimestamp` property while trimming BOM

flatten-bom execution inlines all properties and removes the <properties> block. While this is a good BOM practice, it causes following warnings during build:

project.build.outputTimestamp property should not be inherited but defined in parent POM from reactor /home/vy/Projects/logging-dist-dev/log4j/3.0.0-beta2-src/.flattened-pom.xml

Preferably, project.build.outputTimestamp property should be an exempt to BOM trimming and left as is.

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.

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.

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.

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.

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.

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.

Switch from BeanShell to Groovy

While the BeanShell project is being actively developed, it has not published any new releases to Maven Central since 2016. Similarly Günther's beanshell-maven-plugin didn't have any releases since 2017, even if BeanShell itself has published CVE-2016-2510.

Therefore I would propose to replace our BeanShell scripts with Groovy and use GMavenPlus as binding plugin:

• GMavenPlus comes from a reputable source (the Groovy project) with a huge community,
• the last release is less than 7 months old,
• it's an Apache project 😉.

PS: I am not suggesting that we only stick to plugins backed by a large community, but such projects are more likely to be responsive, when things get interesting.

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.

`distribution` profile cannot process symlinked directories

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

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.

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.

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.

Improve `merge-dependabot-reusable.yaml`

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

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.

Apply uniform code formatting for YAML and JSON

As remarked by @vy in this comment the current Spotless configuration allows YAML files to have a different formatting for empty objects than JSON files.

Enable parallel releases in reusable workflows

Currently, reusable workflows upload the distribution to <projectId> folder. This is problematic when a project wants to do multiple releases simultaneously, e.g., Log4j 2 and Log4j 3. Upload the distribution to <projectId>/<version> folder instead. Note that release instructions need to be updated after this change.

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

Improve release instructions for XSD publication

Release instructions should have a section documenting how to publish XSDs to https://logging.apache.org/xml/ns. It is important to remark in the instructions that every new release of a project doesn't necessarily mean a new XSD. Hence, projectVersion != xsdVersion.

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

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.

Clean up after next `cyclonedx-maven-plugin` upgrade

Once CycloneDX/cyclonedx-maven-plugin#419 is solved and published, we can remove the process-sbom execution and add the external reference to the plugin configuration.