Could you update the changes.md about this?

The fix is in the right place — module POM rather than root. Two notes on the form.

1. Prefer combine.children="append" over repeating the Lombok entry

annotationProcessorPaths inherits with replace semantics, so a child list wins entirely — which is exactly why Lombok has to be repeated here. Maven's combine.children="append" avoids the duplication: the module declares only what it adds, and the parent's entries are inherited.

<annotationProcessorPaths combine.children="append">
    <path>
        <groupId>org.apache.logging.log4j</groupId>
        <artifactId>log4j-core</artifactId>
        <version>${log4j-core.version}</version>
    </path>
</annotationProcessorPaths>

Verified locally — the resulting javac invocation carries both entries, and the descriptor comes back:

-processorpath lombok-1.18.42.jar     <- inherited from the root POM
               log4j-core-2.7.jar     <- declared here
→ META-INF/org/apache/logging/log4j/core/config/plugins/Log4j2Plugins.dat (380 bytes)

Its content is identical to the descriptor shipped in 9.4.0 and earlier: TraceIdConverter, SkyWalkingContextConverter, GRPCLogClientAppender.

The reason to prefer this is not brevity — it is that the replace form reproduces this very bug one level up. If the root POM ever gains another global processor, every module that declared its own annotationProcessorPaths would silently stop receiving it. That is the same silent failure mode being fixed here.

2. On "safe but optional"

The module's Java source files ... do not use Lombok annotations, so adding it to the path is safe but optional.

Accurate today, but the wording invites someone to drop that entry later, and the resulting failure would be precisely the build error #767 fixed — cannot find symbol on a Lombok-generated accessor, with nothing in the diff pointing at the cause. With combine.children="append" the question does not arise at all.

Either way, a guard is still needed

Neither form is self-defending: if the configuration is dropped, reordered, or overridden, the descriptor silently disappears again — no warning, no build failure, just a jar that is missing 380 bytes. Worth adding the build-time assertion the issue suggests, so the next occurrence fails the build instead of reaching three releases. I can send that as a follow-up.

Thanks for the review @wu-sheng. I've updated the PR per both points:

1. CHANGES.md now includes an entry for this fix (referencing [Bug] apm-toolkit-log4j-2.x jar has been missing Log4j2Plugins.dat since 9.5.0, breaking %traceId, %sw_ctx and GRPCLogClientAppender skywalking#14006).
2. pom.xml now uses combine.children="append" on annotationProcessorPaths, so the module declares only the log4j-core processor it adds while keeping the Lombok entry inherited from the root POM — no duplicated entry, and no risk that a future global processor silently stops being applied.

I also verified the mechanism locally: with only Lombok in the processor path, Log4j2Plugins.dat is not generated; appending log4j-core (which carries org.apache.logging.log4j.core.config.plugins.processor.PluginProcessor) brings the descriptor back, and its content contains TraceIdConverter, SkyWalkingContextConverter and the appenders — identical to the 9.4.0 release.

On the build-time guard you mentioned: happy to add it as a follow-up if you'd like, so any future regression fails the build instead of shipping silently.