Re: Staging sites and repo convention

>> It would mean "use logging.staged.apache.org (the ~), but generate the >> content to the subfolder /log4j". >> I left out the magic /content folder since it was a given. This magic folder >> appears to be the problem that I raised with moving the main site to >> logging, at least, that's

Re: [audit] Versioning goals

On Sat, Oct 21, 2023, at 01:02, Ralph Goers wrote: >> On Oct 20, 2023, at 2:38 PM, Christian Grobmeier >> wrote: >> >> Hi, >> >> i just tried to run mvn test/compile etc on audit and wow, i think its a lot >> of work. >> >> What is the target jdk version? It seems as Java 17 already causes

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

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 processor in its own jar. When using JPMS the annotation processor has to be explicitly specified so we really had no choice but

Re: [audit] Versioning goals

> On Oct 20, 2023, at 2:38 PM, Christian Grobmeier wrote: > > Hi, > > i just tried to run mvn test/compile etc on audit and wow, i think its a lot > of work. > > What is the target jdk version? It seems as Java 17 already causes lots of > trouble, even with Java 11 I run into issues, if

Re: Staging sites and repo convention

> On Oct 20, 2023, at 1:37 PM, Christian Grobmeier wrote: > > On Fri, Oct 20, 2023, at 18:43, Ralph Goers wrote: >> If I am reading this correctly that would mean we want all our projects >> to have an empty profile so that they all appear under >> logging.staged.apache.org

[audit] Versioning goals

Hi, i just tried to run mvn test/compile etc on audit and wow, i think its a lot of work. What is the target jdk version? It seems as Java 17 already causes lots of trouble, even with Java 11 I run into issues, if I looked correctly. At least, this code base does not seem to run on newer VMs

[VOTE] Release Apache Log4j 2.21.1 RC1

This is a vote to release the Apache Log4j 2.21.1. Website: https://logging-log4j2.staged.apache.org/log4j GitHub: https://github.com/apache/logging-log4j2 Commit: e613e9ed71279bb52753a4df810d61c11389df81 Distribution: https://dist.apache.org/repos/dist/dev/logging/log4j Nexus:

Re: Staging sites and repo convention

On Fri, Oct 20, 2023, at 18:43, Ralph Goers wrote: > If I am reading this correctly that would mean we want all our projects > to have an empty profile so that they all appear under > logging.staged.apache.org and > logging.apache.org

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

Snippet from the JDK 21 announcement email that pertains to us. While the annotation processor was initially developed to try to be implicit and magic, as we’ve seen both in our build and in IDEs, annotation processing is typically either disabled by default (in IDEs) or sometimes requires

Re: Staging sites and repo convention

If I am reading this correctly that would mean we want all our projects to have an empty profile so that they all appear under logging.staged.apache.org and logging.apache.org … ? Ralph > On Oct 20, 2023, at 12:13 AM, Christian

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

Greetings! JDK 21 has been released (General Availability) on September 19th as planned. You can find "The Arrival of Java 21" announcement here [1], and some additional Java 21 materials in the "Topics of Interest" section below. On behalf of the entire Java team, let me send our thanks to

Re: Staging sites and repo convention

On Fri, Oct 20, 2023, at 09:03, Piotr P. Karwasz wrote: > On Fri, 20 Oct 2023 at 07:55, Ralph Goers wrote: >> As far as the worktree stuff goes, I’d be in favor of that if it can be used >> to solve the issues Piotr mentions where Log4j-Scala and Log4j-Kotlin need >> to be independently

Re: Staging sites and repo convention

Hi Ralph, On Fri, 20 Oct 2023 at 07:55, Ralph Goers wrote: > As far as the worktree stuff goes, I’d be in favor of that if it can be used > to solve the issues Piotr mentions where Log4j-Scala and Log4j-Kotlin need to > be independently committed and merged, although I have a suspicion that

Re: [logging-log4j-jmx-gui] branch release/2.21.1 updated: Bump timestamp

Correct me if I read you wrong: *"you have added a timestamp, so you can update it to trigger the CI"*. Adding a timestamp creates an RM responsibility. It adds one extra manual step to the release procedure. And I am against this. (I think everybody should be against it.) Do you want to trigger

Re: [logging-log4j-jmx-gui] branch release/2.21.1 updated: Bump timestamp

Hi Volkan, On Thu, 19 Oct 2023 at 23:40, Volkan Yazıcı wrote: > > We shouldn’t manually provide a value each time. If you are adamant about > it, we should ideally pass it from command line in CI workflow. But again, > not manually please. This undermines our objective of relieving RM’s load.

Re: Staging sites and repo convention

`worktree`s is a personal preference, I just shared how easy it would be to manage sources next to the website *using a single [git] clone*. Those who want to have multiple clones, can still do so. This has again nothing to do with Piotr's proposal. Piotr's proposal in essence is 1. generate