Re: Staging sites and repo convention

[Piotr P. Karwasz]

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 the 
> ASF web site support would work better if those were in their own repos as I 
> have my doubts they support worktrees.

INFRA does not care about worktrees. Their code is probably something
like: if any `logging-*` repo pushed branch 'lala' that contains an
`.asf.yaml` file with:

staging:
  whoami: lala
  subdir: foo/bar/baz

then copy the content of the branch to `foo/bar/baz`.

Locally you can use a worktree. They might use something else, which
would explain why https://logging-log4j.staged.apache.org is still on,
even if it is not supported by any Git branch.

Piotr

Re: Staging sites and repo convention

[Christian Grobmeier]

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 committed and merged, although I have a suspicion that 
>> the ASF web site support would work better if those were in their own repos 
>> as I have my doubts they support worktrees.
>
> INFRA does not care about worktrees. Their code is probably something
> like: if any `logging-*` repo pushed branch 'lala' that contains an
> `.asf.yaml` file with:

It matches the repo name to the project, i.e. 

logging-site -> logging project logging.staged.a.o
logging-log4j-site -> also logging project, logging.staged.a.o

With the profiles, you can manage subdomains

profile: ~ -> logging.s.a.o directly
profile: main - > logging-main.logging.s.a.o

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

[David Delabassee]

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 all of you. Through 
your active participation in this program, you are helping shape the Java 
platform!

Needless to say, that Java 21 is an important release, so may I ask you to send 
me a brief email with the Java 21 support status of your project(s): Already 
supported - Plan to support short-term - Don't plan to support short-term ?

And now that JDK 21 is out, let's shift our attention to JDK 22 which will 
enter the Rampdown Phase in less than 50 days on December 7 [2].

I want to conclude this update by briefly mentioning three different 
initiatives to are relevant to this group as they are, in their own way and at 
various levels, contributing to adopt newer Java releases more rapidly: the 
Class-File API, Oracle's Java Platform extension for VS Code, and the Java 
Playground.

### The Class-File API

The Class-File API is a new standard API for parsing, generating, and 
transforming Java class files. One of its unique aspects is that it will 
co-evolve with the class-file format, which overtime will greatly reduce the 
friction of implementing new class-file features. With the fast-paced evolution 
of the Java platform, this was much-needed. This API should soon be previewed 
and as it matures, we expect the JDK to switch from using various custom 
class-file libraries to this standard API. We also expect that overtime 
frameworks relying on bytecode manipulation will also benefit from using this 
new JDK class-file library. For more information, please check this recent 
Newscast [3] for an overview, Brian Goetz's JVMLS session [4] for more details 
and design considerations, and JEP 457: Class-File API (Preview) [5] for the 
technical details.

### Oracle's Java Platform extension for Visual Studio Code

Oracle has just announced [6] a new Visual Studio Code extension for Java 
developers. Unlike other VS Code extensions, this new extension is using under 
the hood the `javac` compiler for code editing and compilation, and OpenJDK's 
debugger interface for debugging. This enables us to offer VS Code IDE support 
for new JDK features as soon as they are introduced, even during JDK Early 
Access phases. To this effect, this VS Code Extension will support the current 
JDK releases as well as the next upcoming JDK version. For more information, 
please check the announcement [6].

### The Java Playground

The Java Playground [7] is an online sandbox that helps testing and exploring 
new Java language features. No setup required, just type your Java snippet in 
your browser and run it! Right now, the Playground is using Java 21 with 
Preview Features enabled, and it will switch to a new Java version as soon as 
there is a new Java language features integrated in OpenJDK Early-Access 
builds. The Playground is focusing mostly on Project Amber and is certainly not 
mean to be some sort of a lightweight online-IDE, it is instead a learning tool 
to play with new Java language feature shortly after they have been integrated 
into the platform.

[1] https://inside.java/2023/09/19/the-arrival-of-java-21/
[2] https://mail.openjdk.org/pipermail/jdk-dev/2023-September/008269.html
[3] https://www.youtube.com/watch?v=bQ2Rwpyj_Ks
[4] https://www.youtube.com/watch?v=pcg-E_qyMOI
[5] https://openjdk.org/jeps/457
[6] https://inside.java/2023/10/18/announcing-vscode-extension/
[7] https://dev.java/playground


## Heads-Up - JDK 22: Implicit Annotation Processing Behavior Change

As discussed in the July 2023 Quality Outreach update [8], starting in JDK 21 
javac emits a note if _implicit_ annotation processing is being used, that is, 
if one or more annotation processors are found and run from the class path when 
no explicit annotation processing configuration options are used.

The note is reported since, quoting from the note text: "A future release of 
javac may disable annotation processing unless at least one processor is 
specified by name (-processor), or a search path is specified 
(--processor-path, --processor-module-path), or annotation processing is 
enabled explicitly (-proc:only, -proc:full)."

That future version of javac has arrived in JDK 22 b19+ with JDK-8306819 
("Consider disabling the compiler's default active annotation processing"). In 
the situation where a note was emitted in JDK 21, in JDK 22 no note is emitted, 
and annotation processors are *not* run. To restore the previous behavior with 
respect to running annotation processors, add the '-proc:full' javac option.

Feedback on the annotation processing policy change can be sent to compiler-dev 
[9].

[8] https://mail.openjdk.org/pipermail/quality-discuss/2023-July/001122.html
[9] https://mail.openjdk.org/mailman/listinfo/compiler-dev


## JDK 

Re: Staging sites and repo convention

[Ralph Goers]

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 Grobmeier  
> wrote:
> 
> 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 committed and merged, although I have a suspicion 
>>> that the ASF web site support would work better if those were in their own 
>>> repos as I have my doubts they support worktrees.
>> 
>> INFRA does not care about worktrees. Their code is probably something
>> like: if any `logging-*` repo pushed branch 'lala' that contains an
>> `.asf.yaml` file with:
> 
> It matches the repo name to the project, i.e. 
> 
> logging-site -> logging project logging.staged.a.o
> logging-log4j-site -> also logging project, logging.staged.a.o
> 
> With the profiles, you can manage subdomains
> 
> profile: ~ -> logging.s.a.o directly
> profile: main - > logging-main.logging.s.a.o
> 
> 
> 

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

[Matt Sicker]

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 manual setup anyways 
(like in our build). It sounds like starting in Java 22, implicit annotation 
processing will no longer be available. We’ll need to ensure our docs about 
this mention that you need to enable annotation processing in your build, too.

> Begin forwarded message:
> 
> From: David Delabassee 
> Subject: JDK 21 Is Now GA, a New VS Code Extension, and an Annotation 
> Processing Heads-up
> Date: October 20, 2023 at 4:39:07 AM CDT
> To: "dev@logging.apache.org" 
> Reply-To: dev@logging.apache.org
> List-Id: 
> 
> ## Heads-Up - JDK 22: Implicit Annotation Processing Behavior Change
> 
> As discussed in the July 2023 Quality Outreach update [8], starting in JDK 21 
> javac emits a note if _implicit_ annotation processing is being used, that 
> is, if one or more annotation processors are found and run from the class 
> path when no explicit annotation processing configuration options are used.
> 
> The note is reported since, quoting from the note text: "A future release of 
> javac may disable annotation processing unless at least one processor is 
> specified by name (-processor), or a search path is specified 
> (--processor-path, --processor-module-path), or annotation processing is 
> enabled explicitly (-proc:only, -proc:full)."
> 
> That future version of javac has arrived in JDK 22 b19+ with JDK-8306819 
> ("Consider disabling the compiler's default active annotation processing"). 
> In the situation where a note was emitted in JDK 21, in JDK 22 no note is 
> emitted, and annotation processors are *not* run. To restore the previous 
> behavior with respect to running annotation processors, add the '-proc:full' 
> javac option.
> 
> Feedback on the annotation processing policy change can be sent to 
> compiler-dev [9].
> 
> [8] https://mail.openjdk.org/pipermail/quality-discuss/2023-July/001122.html
> [9] https://mail.openjdk.org/mailman/listinfo/compiler-dev

Re: Staging sites and repo convention

[Christian Grobmeier]

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 … ?

Please take everything cautiously because this knowledge is new to me, and I 
may make mistakes - but yes, this is correct.

>From the log4j profile (latest commit changed something):
https://github.com/apache/logging-log4j-site/commit/048bb9983cfb7e8549801c8a491a2adb0a6de433

It reads:

staging:
  profile: ~
  whoami: asf-staging
  subdir: content/log4j

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 what I understood from infra: because of the bug, we would 
generate to /output, which confused the server.

If you want to maintain flume:

staging:
  profile: ~
  whoami: asf-staging
  subdir: content/flume

The same goes for asf-site, which is then deployed to the public destination.

You can look at the current config on this tool (for production sites only, it 
seems):
https://infra-reports.apache.org/#sitesource

Christian

[VOTE] Release Apache Log4j 2.21.1 RC1

[Piotr P. Karwasz]

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: https://repository.apache.org/content/repositories/orgapachelogging-1209
Signing key: 0x077e8893a6dcc33dd4a4d5b256e73ba9a0b592d0

Please download, test, and cast your votes on this mailing list.

[ ] +1, release the artifacts
[ ] -1, don't release, because...

This vote is open for 72 hours and will pass unless getting a
net negative vote count. All votes are welcome and we encourage
everyone to test the release, but only the Logging Services PMC
votes are officially counted.

== Countdown

https://www.timeanddate.com/countdown/party?iso=20231023T2320&p0=1449&font=cursive

== Release Notes

This patch release contains only the fix of a `log4j-jcl` bug that
prevents it from connecting with `commons-logging`.

The Log4j 2.21.1 API, as well as the other artifacts, maintains binary
compatibility with the previous release.

Apache Log4j 2.21.1 requires Java 8 to run.
The build requires JDK 11 and generates reproducible binaries.

For complete information on Apache Log4j 2, including instructions on
how to submit bug reports, patches, get support, or suggestions for
improvement, see http://logging.apache.org/log4j/2.x/[the Apache Log4j
2 website].


=== Fixed

* Fixes the Apache Commons Logging (JCL) bridge: `log4j-jcl`. (#1865)

Piotr

[audit] Versioning goals

[Christian Grobmeier]

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

Kind regards,
Christian

Re: Staging sites and repo convention

[Ralph Goers]

> 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  and 
>> logging.apache.org … ?
> 
> Please take everything cautiously because this knowledge is new to me, and I 
> may make mistakes - but yes, this is correct.
> 
> From the log4j profile (latest commit changed something):
> https://github.com/apache/logging-log4j-site/commit/048bb9983cfb7e8549801c8a491a2adb0a6de433
> 
> It reads:
> 
> staging:
>  profile: ~
>  whoami: asf-staging
>  subdir: content/log4j
> 
> 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 what I understood from infra: because of the bug, we would 
> generate to /output, which confused the server.

Yes. I can see how this would confuse it. When you changed the main site to use 
output instead of content you essentially deleted the content directory. So 
then the sub-project web sites had nowhere to live. We would have had to change 
all the sub-projects to switch to using output as well to fix it.

Ralph

Re: [audit] Versioning goals

[Ralph Goers]

> 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 I looked correctly. At 
> least, this code base does not seem to run on newer VMs

I am quite sure it used Java 8. When I start updating it one of the first 
things will be to upgrade Spring and to Java 11. I’m not quite prepared to 
upgrade to Spring Boot 3 and Java 17 yet.

Ralph

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

[Ralph Goers]

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 to do this. I 
suspect this isn’t documented as well as it should be though.

Ralph

> On Oct 20, 2023, at 10:38 AM, Matt Sicker  wrote:
> 
> 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 manual 
> setup anyways (like in our build). It sounds like starting in Java 22, 
> implicit annotation processing will no longer be available. We’ll need to 
> ensure our docs about this mention that you need to enable annotation 
> processing in your build, too.
> 
>> Begin forwarded message:
>> 
>> From: David Delabassee 
>> Subject: JDK 21 Is Now GA, a New VS Code Extension, and an Annotation 
>> Processing Heads-up
>> Date: October 20, 2023 at 4:39:07 AM CDT
>> To: "dev@logging.apache.org" 
>> Reply-To: dev@logging.apache.org
>> List-Id: 
>> 
>> ## Heads-Up - JDK 22: Implicit Annotation Processing Behavior Change
>> 
>> As discussed in the July 2023 Quality Outreach update [8], starting in JDK 
>> 21 javac emits a note if _implicit_ annotation processing is being used, 
>> that is, if one or more annotation processors are found and run from the 
>> class path when no explicit annotation processing configuration options are 
>> used.
>> 
>> The note is reported since, quoting from the note text: "A future release of 
>> javac may disable annotation processing unless at least one processor is 
>> specified by name (-processor), or a search path is specified 
>> (--processor-path, --processor-module-path), or annotation processing is 
>> enabled explicitly (-proc:only, -proc:full)."
>> 
>> That future version of javac has arrived in JDK 22 b19+ with JDK-8306819 
>> ("Consider disabling the compiler's default active annotation processing"). 
>> In the situation where a note was emitted in JDK 21, in JDK 22 no note is 
>> emitted, and annotation processors are *not* run. To restore the previous 
>> behavior with respect to running annotation processors, add the '-proc:full' 
>> javac option.
>> 
>> Feedback on the annotation processing policy change can be sent to 
>> compiler-dev [9].
>> 
>> [8] https://mail.openjdk.org/pipermail/quality-discuss/2023-July/001122.html
>> [9] https://mail.openjdk.org/mailman/listinfo/compiler-dev
> 

Re: [audit] Versioning goals

[Christian Grobmeier]

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 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
>
> I am quite sure it used Java 8. When I start updating it one of the 
> first things will be to upgrade Spring and to Java 11. I’m not quite 
> prepared to upgrade to Spring Boot 3 and Java 17 yet.

What does "not quite prepared" mean - you don't want too, or you can't for a 
technical reason?

I already saw one would have to add this dependency:

  
javax.annotation
javax.annotation-api
1.3.2
  

For @PreDestroy/Construct

Re: Staging sites and repo convention

[Christian Grobmeier]

>> 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 what I understood from infra: because of the bug, 
>> we would generate to /output, which confused the server.
>
> Yes. I can see how this would confuse it. When you changed the main 
> site to use output instead of content you essentially deleted the 
> content directory. So then the sub-project web sites had nowhere to 
> live. We would have had to change all the sub-projects to switch to 
> using output as well to fix it.

Yes, that is what I was told too. Meanwhile, my fix worked and even Jekyll 
works with content now. 
However, the staging server seems to be in a bad "state", that's why I asked 
infra to help and maybe clean it.
Once they do this, everything is back to normal, which is currently my goal. I 
really would love to have a working Jekyll site now, with all the news we have 
coming in.

Piotrs proposal is a different thing to me, and I don't have an opinion about 
this yet. In the end, I agree with you and Piotr as well that we should keep 
the existing URLs for the next 30 years or so