Re: Staging sites and repo convention

On Sun, Oct 22, 2023, at 21:54, Volkan Yazıcı wrote: > It has been a long thread and I want to capture the result: *there are no > objections to Piotr's proposal, right?* If not, please say so. I am not objecting, but I would like to point out that logging.s.a.o is in bad shape today, and I

Re: Staging sites and repo convention

Hi Volkan, On Sun, 22 Oct 2023 at 23:47, Volkan Yazıcı wrote: >2. Instead of using logging.*staged.*apache.org*/foo*, we will use >logging*-foo.staged.*apache.org for staging websites. >3. Log4j Scala, Kotlin, Tools, and Transformation website content will >be moved from

Re: Staging sites and repo convention

It has been a long thread and I want to capture the result: *there are no objections to Piotr's proposal, right?* If not, please say so. To avoid misunderstanding, I want to repeat certain points one more time: 1. All existing logging.apache.org URLs will remain as is – no changes there.

Re: JDK 21 Is Now GA, a New VS Code Extension, and an Annotation Processing Heads-up

Yeah I think it’s mainly a documentation thing for 3.x. — Matt Sicker > On Oct 20, 2023, at 18:06, Ralph Goers wrote: > > I don’t think this is a problem. Only users of Log4j 3.x should be using Java > 17 and up by the time this makes it to an LTS release. Log4j 3.x has put the > annotation

Re: [log4j] Project URLs per major version

Hi Volkan, On Sun, 22 Oct 2023 at 22:20, Volkan Yazıcı wrote: >3. *Don't create a new folder for every release, but override the `2.x` >folder.* > - This is okay, since we keep backward compatibility in minor+patch > releases and explicitly provide version for features that

Re: [log4j] Annotation processing alternatives

Hi Matt, On Sun, 22 Oct 2023 at 22:49, Matt Sicker wrote: > So now we come to your question about a factories file. That’s an interesting > idea, though it’s extremely similar to what we’re doing here with > ServiceLoader (though the split between META-INF/services/ files and >

Re: [log4j] Project URLs per major version

This sounds pretty cool Volkan, if I didn't get anything I pretty much like it. One question - you wrote: "we all will enjoy automatically populated Log4j websites." Does this mean we will see our website is updated automatically by CI so we can see in example /log4j/dev? Or what else is

Re: [log4j] Annotation processing alternatives

Let me expand on this question with further context as it relates to why the annotation processor exists in the first place. Back when the initial plugin system was developed by Ralph, we had an option to specify a comma-separated list of packages to scan for plugins (note that scanning the

[log4j] Project URLs per major version

Currently, we have the following folder structure in the `logging-log4j-site` repository for the Log4j project: - `log4j-1.2.17` – the website generated by the last Log4j 1 release, i.e, `1.2.17` - `log4j-1.2` – symlinks to `log4j-1.2.17` - `1.x` – symlinks to `log4j-1.2.17` - ...

[log4j] Annotation processing alternatives

Good point Matt! Annotation processing has always been an unpleasant magic to work with from a developer perspective for the reasons you shared. What are our alternatives? Can't we offer a `META-INF/log4j.factories` functionality similar to Spring Boot? If so, 1. What are its cons/pros for

Re: [VOTE] Release Apache Log4j 2.21.1 RC1

+1 Checked sigs, hashes, reproducibility, and commits compared to `rel/2.21.0` tag. On Fri, Oct 20, 2023 at 11:20 PM Piotr P. Karwasz wrote: > This is a vote to release the Apache Log4j 2.21.1. > > Website: https://logging-log4j2.staged.apache.org/log4j > GitHub: