Add transitive compileOnlyApi (requires static) dependencies

[jjohannes]

This pull requests adds compileOnlyApi dependencies (Gradle Module Metadata) and requires static (module-info) for all annotation libraries used in Log4j. See #3437 for details.

The following example can be used to test the effects of the change in a Gradle build on a locally built snapshot:
https://github.com/jjohannes/gradle-demos/tree/main/log4j-metadata

Checklist

• Base your changes on 2.x branch if you are targeting Log4j 2; use main otherwise
• ./mvnw verify succeeds (if it fails due to code formatting issues reported by Spotless, simply run ./mvnw spotless:apply and retry)
• Non-trivial changes contain an entry file in the src/changelog/.2.x.x directory
• Tests for the changes are provided
• Commits are signed (optional, but highly recommended)

[vy]

@jjohannes, I've just released logging-parent version 12.0.0. It contains breaking changes touching these dependencies. dependabot should automatically update logging-parent version in /pom.xml. Would you mind keeping an eye on it, and once the update kicks in, make necessary adjustments to this PR, please?

[vy]

@ppkarwasz, shall we also add a test for this to log4j-samples?

[github-actions]

Job	Requested goals	Build Tool Version	Build Outcome	Build Scan®
build-macos-latest	clean install	3.9.8	✅
build-ubuntu-latest	clean install	3.9.8	✅
build-windows-latest	clean install	3.9.8	✅

Generated by gradle/develocity-actions

[ppkarwasz]

@ppkarwasz, shall we also add a test for this to log4j-samples?

What test do you have in mind? Do we test that a certain dependency is in the Gradle compileClasspath configuration, but is not in the Gradle runtimeClasspath?

[jjohannes]

@vy I rebased the PR and re-tested. I also checked the changes in logging-parent:12.0.0 - there were no conflicts.

If it fits, the sample Gradle project I created could be moved to log4j-samples. I added a check that asserts what is ending up on the classpaths if you only add the log4j-api. So running ./gradlew build on that sample would be a quite good "end-to-end" test for the metadata publishing.

[vy]

If it fits, the sample Gradle project I created could be moved to log4j-samples. I added a check that asserts what is ending up on the classpaths if you only add the log4j-api. So running ./gradlew build on that sample would be a quite good "end-to-end" test for the metadata publishing.

@jjohannes, sounds plausible, thanks! We can run ./gradlew build either as a part of the integration-test.yaml workflow, or add it under a Maven module and run the command (using antrun-maven-plugin?), etc. @ppkarwasz, WDYT?

[ppkarwasz]

@jjohannes, sounds plausible, thanks! We can run ./gradlew build either as a part of the integration-test.yaml workflow, or add it under a Maven module and run the command (using antrun-maven-plugin?), etc. @ppkarwasz, WDYT?

I would prefer not to use antrun-maven-plugin, lets have a separate Gradle run instead. We could think about merging some jobs in integration-test.yaml workflow. Currently we have:

1. a Maven-based run for most of the example modules.
2. a Maven-based run for the GraalVM test.
3. a Gradle-based run for the Android test.

Since 1 and 2 only differ by the JDK used, we could use the GraalVM JDK for both and merge them.
I would be also nice to merge the new test module with the Android test, although I don't how to properly do it.

[jjohannes]

What you could do is rename workflows/android-reusable-test.yaml to something like gradle-tests.yaml.

Then you can add another step that runs Gradle against the new example similar to this one that runs the Android example.

If that sounds like a good way forward to you, I can provide a (Draft) PR with the new example.

[ppkarwasz]

If that sounds like a good way forward to you, I can provide a (Draft) PR with the new example.

Sounds good to me.

[vy]

@jjohannes, I liked this proposal. Looking forward to your PR.

Note that both @ppkarwasz and I are swamped with work at the moment. Please be patient while waiting for feedback and/or reviews.

[jjohannes]

Here is the PR for the samples repo: apache/logging-log4j-samples#279
Hope I did not miss anything important there.

@vy no problem. There is no urgency from my side. Let me know if I can help with anything else.

[vy]

@jjohannes, thanks so much for the fix!

@ppkarwasz, changes LGTM. Would you mind also skimming through, please?

[ppkarwasz]

Looks good to me.

There is one missing annotation library and we are good to go!

[ppkarwasz]

Can you add org.osgi.annotation.versioning too?