[log4j] `.asf.yaml` between branches

Piotr, I have seen you applied this *"sync'ing `asf.yaml` between branches"* practice in `logging-parent` too. I find this new setup - *confusing* – Previously, say, `asf-site` related configuration was only in the `asf-site` branch. Now it is in multiple branches of which it has no assoc

Website repos/branches (again)

Hi, As we discussed yesterday the way our website is created from multiple repos and branches is somehow incoherent: some parts of the website have separate repos, other parts have a branch in a code repo, other parts have a branch in a website repo. For example: * the `/log4j/jakarta` directory

Re: [log4j] `.asf.yaml` between branches

Hi Volkan, On Mon, 15 Jan 2024 at 09:28, Volkan Yazıcı wrote: > Piotr, I have seen you applied this *"sync'ing `asf.yaml` between branches"* > practice in `logging-parent` too. I find this new setup > >- *confusing* – Previously, say, `asf-site` related configuration was >only in the `asf

[ANNOUNCE] Apache Logging Parent 10.6.0 released

Apache Logging Parent team is pleased to announce the 10.6.0 release. This project contains the parent POM for other Maven-based Apache Logging Services projects. For further information (support, download, etc.) see the project website[1]. === Release Notes This minor release contains several sm

Re: Website repos/branches (again)

-1 on merging multiple websites to a single repository. I think documentation should reside in the same repository where sources are. I already implemented this for *almost* every repository: logging-parent logging-log4j-tools logging-log4j-transform logging-log4j-kotlin logging-log4j-scala loggi

Re: [log4j] `.asf.yaml` between branches

On Mon, Jan 15, 2024 at 9:45 AM Piotr P. Karwasz wrote: > This setup has some pros: > > * you don't need to navigate to all the website branches to see how > they are configured, > This would only work *iff* the `.asf.yaml` between the branch you are looking at (e.g., `main`) and the target bra

Re: Website repos/branches (again)

On Mon, 15 Jan 2024 at 10:40, Volkan Yazıcı wrote: > > -1 on merging multiple websites to a single repository. > > I think documentation should reside in the same repository where sources > are. I already implemented this for *almost* every repository: > > logging-parent > logging-log4j-tools > lo

Re: [log4j] `.asf.yaml` between branches

Hi Volkan, On Mon, 15 Jan 2024 at 11:07, Volkan Yazıcı wrote: > > * you can stage the website for a release with a simple: > > > > git checkout asf-staging > > git reset --hard asf-site > > unzip ... > > git push -f > > > > You can do the same in the existing setup too. You just need a `sed` > o

[log4j] Performance figures

*TLDR:* I want to remove performance figures from the Log4j website, because they don't serve any practical value anymore. Log4j website shares performance figures in several pages; Performance , Asynchronous Logging

Re: [log4j] Performance figures

We should IMO keep this information available _somewhere_, maybe in a new stable historical-archival section of the site. I'm not a fan of using the wiki because that's yet another place to look for information and it feels transitory, unstable (as far as information permanance), and more like some

Re: [log4j] `.asf.yaml` between branches

Even though it wouldn't be of my preference, keeping both `staging` and `publish` configuration in `asf-site` sounds like a middle ground I can live with. I will appreciate it if you can adapt your existing changes (in `logging-log4j-kotlin`, `logging-parent`, etc.) to comply with this, unless you

Should we keep `log4j-appserver` and `log4j-jcl` in 3.x?

Hi all, While 3.x is approaching its first stable release as a meteor burning through the sky, its core is getting smaller as it approaches earth. That is why I would propose to remove two further modules from 3.x: * The functionality of `log4j-jcl` is included in `commons-logging` version 1.3.

[log4j] Remove `XmlLayout` from `main`

I asked Gary if he can re-evaluate his decision on `XmlLayout`, since he was the only one who requested to keep it in `main`. He kindly checked this in his employer's codebase, could not locate any `XmlLayout` usage, and agreed to drop it from `main`. (Thank you Gary! 🙇) I will implement this chang

Re: Should we keep `log4j-appserver` and `log4j-jcl` in 3.x?

+1 Allow me to remind everyone that anything that is removed from `3.0.0` can be added again in a follow up minor release, if need arises. Hence, no need to be overcautious. On Mon, Jan 15, 2024 at 9:50 PM Piotr P. Karwasz wrote: > Hi all, > > While 3.x is approaching its first stable release a

Re: [log4j] `.asf.yaml` between branches

I don’t understand what it means to keep both staging and publish in “asf-site”. By definition, the asf-site branch is the live web-site and asf-staging is the staging web site. Are you talking about the build scripts or something? I started to reply to this earlier today but got sidetracked

Re: Should we keep `log4j-appserver` and `log4j-jcl` in 3.x?

I am OK with this. It would be best if we could get Tomcat to publish a tomcat-log4j artifact. Ralph > On Jan 15, 2024, at 1:50 PM, Piotr P. Karwasz wrote: > > Hi all, > > While 3.x is approaching its first stable release as a meteor burning > through the sky, its core is getting smaller as i

Re: [log4j] `.asf.yaml` between branches

Hi Ralph, On Tue, 16 Jan 2024 at 01:56, Ralph Goers wrote: > > I don’t understand what it means to keep both staging and publish in > “asf-site”. By definition, the asf-site branch is the live web-site and > asf-staging is the staging web site. Are you talking about the build scripts > or som

Re: [log4j] Performance figures

I’m open to improvements in this area. Before going into details or specifics though, I’m curious: What do we (users, developers and PMC members) consider to be the “value proposition” of Log4j? Why should people choose Log4j over the alternatives? This is a positioning question; what are the