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
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
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
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
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
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
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
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
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
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
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
11 matches
Mail list logo