Re: Bridges in 2.x and 3.x

2024-11-03 Thread Piotr P. Karwasz
Gary, On 25.10.2024 08:19, Ralph Goers wrote: With the changes that have been made the bridges only have a dependency on Logj4 API - which is only in the 2.x branch. Should these artifacts only be on the 2.x branch as well? These bridges don’t change nearly as often as core or even api do. IM

Re: Bridges in 2.x and 3.x

2024-10-24 Thread Ralph Goers
Gary, With the changes that have been made the bridges only have a dependency on Logj4 API - which is only in the 2.x branch. Should these artifacts only be on the 2.x branch as well? These bridges don’t change nearly as often as core or even api do. IMO releasing them with every release does

Re: Bridges in 2.x and 3.x

2024-10-24 Thread Piotr P. Karwasz
Hi Gary, On 23.10.2024 12:50, Gary D. Gregory wrote: Another batch of repositories? -1 and you must be joking. We really are going off the map here IMO :( Releasing different jars from one repo is the same as releasing jars from one SSD: A repo is just a folder with subfolders you can organiz

Re: Bridges in 2.x and 3.x

2024-10-23 Thread Piotr P. Karwasz
Hi Gary, On Wed, 23 Oct 2024 at 13:11, Gary D. Gregory wrote: > - `jul-to-log4j-core`: I understand that name as: The JUL API is implemented > in terms of Log4j's own impl guts. The difference with `jul-to-log4j-api` is > that we directly implement JUL? Without going though log4j-api? If that's

Re: Bridges in 2.x and 3.x

2024-10-23 Thread Piotr P. Karwasz
Hi Gary, On Wed, 23 Oct 2024 at 12:51, Gary D. Gregory wrote: > Releasing different jars from one repo is the same as releasing jars from one > SSD: A repo is just a folder with subfolders you can organize as you best see > fit. So why have 10 repos? Or how ever many we have now splintered Log4

Re: Bridges in 2.x and 3.x

2024-10-23 Thread Gary D. Gregory
I like the idea of revisiting our jar names Volkan. Thank you for bringing this up. I _always_ have to lookup how to layer jars whenever I have to deal with a complex stack that usually involves Log4j, JUL, and Slf4j. "bullet-proof self-explanatory names": Yes, please! I like using the "-api" p

Re: Bridges in 2.x and 3.x

2024-10-23 Thread Gary D. Gregory
Another batch of repositories? -1 and you must be joking. We really are going off the map here IMO :( Releasing different jars from one repo is the same as releasing jars from one SSD: A repo is just a folder with subfolders you can organize as you best see fit. So why have 10 repos? Or how eve

Re: Bridges in 2.x and 3.x

2024-10-23 Thread Piotr P. Karwasz
Hi all, On Tue, 22 Oct 2024 at 18:52, Piotr P. Karwasz wrote: > Since I would like to release `3.0.0-beta3` some time soon and we did > not reach a larger consensus, I propose to: > > - Remove **all** the bridges from `3.0.0-beta3`, with the exception of > `Log4jBridgeHandler`, which is not an AP

Re: Bridges in 2.x and 3.x

2024-10-22 Thread Ralph Goers
I am OK with this plan. I understand why Volkan wants -api though. If log4j-api was named ALA4J (Apache Logging API for Java) then you would rightfully want to name the bridge slf4j-to-ala4j. By naming it slf4j-to-log4j it is ambiguous. Ralph > On Oct 22, 2024, at 9:52 AM, Piotr P. Karwasz w

Re: Bridges in 2.x and 3.x

2024-10-22 Thread Piotr P. Karwasz
Hi Volkan On Thu, 10 Oct 2024 at 21:36, Volkan Yazıcı wrote: > > I am in favor of the rebranding approach and covering all bridges. That is, > I suggest adding new modules to `2.x` with bullet-proof self-explanatory > names, e.g., > >- `*log4j-api*-to-slf4j` I like the idea, although I would

Re: Bridges in 2.x and 3.x

2024-10-10 Thread Volkan Yazıcı
I am in favor of the rebranding approach and covering all bridges. That is, I suggest adding new modules to `2.x` with bullet-proof self-explanatory names, e.g., - `*log4j-api*-to-slf4j` - `slf4j-to-*log4j-api*` – It is clear that this is an API-to-API bridge. Nobody can cry with *"Oh! Ge