Avoid referring to PluginBuilderAttribute.class in PluginProcessor#4041
Avoid referring to PluginBuilderAttribute.class in PluginProcessor#4041vy merged 2 commits intoapache:2.xfrom
PluginBuilderAttribute.class in PluginProcessor#4041Conversation
This makes it easier to build PluginProcessor by itself separately from the rest of log4j-core, and then include that processor when building the rest of core, instead of having to compile all of core twice.
|
@cushon, I'm sorry for the late reply. All of my Log4j time was sucked by AI slop — Piotr mentioned about it in #4052.
If so, we should be able to simplify the |
|
@vy thanks for taking a look!
I'm open to trying that, I'm not sure exactly how it would work yet. I noticed this issue trying to build log4j2 with Bazel, not using the maven build, I am less familiar with maven. This change makes it possible to build the plugins by building just the following sources: So it would still be necessary to compile those parts of log4j-core twice, but it might be possible to compile just the above sources in the first phase. Another option I was wondering about is whether it might be possible to move these processors to a separate maven submodule, to compile them separately before |
PluginBuilderAttribute.class in PluginProcessor
Would you mind elaborating on this a bit, please? Do you have an in-house Log4j build using Bazel?
That'd be a disruptive change. |
Generated by gradle/develocity-actions |
Yes, we have in-house Bazel builds for some dependencies as an alternative to maven/gradle builds or published prebult jars. |
#4041) This makes it easier to build `PluginProcessor` by itself separately from the rest of `log4j-core`, and then include that processor when building the rest of core, instead of having to compile all of core twice.
This makes it easier to build PluginProcessor by itself separately from the rest of log4j-core, and then include that processor when building the rest of core, instead of having to compile all of core twice.