Agreed. I added the BOM POM later on and didn’t know of any established
patterns for modules as BOMs weren’t used extensively quite yet at the time
(and it was a Maven specific feature then, too; Spring ported the concept to
Gradle later on, and now Gradle has a native concept of the same thing)
I’d like to add more ConditionalOn annotations for the @Factory methods, or at
least something like “if no binding exists for this key already, here it is”
which is analogous to @ConditionalOnMissingBean in Spring. That would make the
DefaultCallback code easier to write without using the Inject
> On May 19, 2022, at 12:15 AM, Volkan Yazıcı wrote:
>
> In the last couple of weeks, I have been interrogating Matt on why and how
> of the 3.x plugin infra. This inevitably led to some code archaeology. I
> will try to share my take out of this exercise.
>
> 1.x required users to type the f
Yes, that would make sense. I am sure this happened simply because the bom
pom.xml was introduced way after the first releases.
Ralph
> On May 18, 2022, at 11:38 PM, Volkan Yazıcı wrote:
>
> Even though we provide a BOM module (`log4j-bom`), we don't consume it
> ourselves. Hence occasionally
In the last couple of weeks, I have been interrogating Matt on why and how
of the 3.x plugin infra. This inevitably led to some code archaeology. I
will try to share my take out of this exercise.
1.x required users to type the fully-qualified class names of components
(appenders, layouts, etc.) in
