I do like this as a separate repo. If I understand what you are intending I 
expect that releasing this tool will be big news:
1. It automatically converts calls to SLF4J to Log4j, eliminating the need to 
include the SLF4J and log4j-slf4j-impl jars at runtime.
2. It adds location information for free for both SLF4J and Log4j API calls, 
which should be a significant performance improvement.

One gotcha we will need to make sure is accounted for is the use of Lombok. 
Will the tool be able to find the Logger created by Lombok?

Ralph

> On Jan 3, 2023, at 12:35 PM, Volkan Yazıcı <vol...@yazi.ci> wrote:
> 
> `logging-log4j-transform` and `org.apache.logging.log4j` are fine by me.
> 
> On Tue, Jan 3, 2023 at 6:43 PM Piotr P. Karwasz <piotr.karw...@gmail.com>
> wrote:
> 
>> Hi Volkan,
>> 
>> On Tue, 3 Jan 2023 at 09:45, Volkan Yazıcı <vol...@yazi.ci> wrote:
>>>   1. Create a new `logging-log4j-infra` (groupId: `o.a.l.l.infra`)
>>>   repository and move the `log4j-changelog` module there and put Piotr's
>>>   stuff into `logging-log4j-tools` (groupId: `o.a.l.l.tools`)
>>>   2. Move everybody to their own repo: `logging-log4j-changelog`,
>>>   `logging-log4j-instrument`, `logging-log4j-errorprone`, etc. This
>> might
>>>   turn out to be a better approach given aforementioned projects will
>> most
>>>   probably have totally different development cycles.
>> 
>> What about `logging-log4j-transform`? The Maven plugin could be called
>> `log4j-transform-maven-plugin` in case we publish other plugins.
>> 
>> For the groupId I think `org.apache.logging.log4j` that Ralph proposes
>> will be fine.
>> 
>> Piotr
>> 

Reply via email to