Re: [VOTE][LAZY] Release Apache Logging Parent 10.1.0

[Volkan Yazıcı]

I have issued an RC2 with following differing properties:

Commit: 5484f2d41b593b71e4465807a658482647ef5519
Nexus:
https://repository.apache.org/content/repositories/orgapachelogging-1184

It incorporates following changes over RC1:

- Updated `org.apache:apache` to version `30`
- Improved OSGi `Bundle-SymbolicName` auto-generation
- Added `true` to `maven-compiler-plugin` config

I will continue publishing this RC2 without waiting for further feedback.

On Wed, Sep 27, 2023 at 1:34 PM Volkan Yazıcı  wrote:

> This is a lazy-vote to release the Apache Logging Parent 10.1.0.
>
> Source repository: https://github.com/apache/logging-parent
> Commit: d19ac4a1e3b324bb22b3379d48dcada50f24c65b
> Distribution:
> https://dist.apache.org/repos/dist/dev/logging/logging-parent
> Nexus:
> https://repository.apache.org/content/repositories/orgapachelogging-1180
> 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 24 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.
>
> === Release Notes
>
> This minor release focuses on shipping AsciiDoc-based website
> generation convenience targeting the `src/site` folder. As a part of
> this effort, `logging-parent` started publishing its own website[1]
> and `log4j-changelog` support switched from Markdown to AsciiDoc.
>
> [1] https://logging.staged.apache.org/logging-parent
>
> The introduced `bnd-maven-plugin` default auto-generates both OSGi and
> JPMS descriptors. Users only need to annotate packages that are to be
> exported with `org.osgi.annotation.bundle.Export`, plugin will do the
> rest of the magic. Hence, no need for custom `.bnd` and/or
> `module-info.java` files anymore. In particular, we expect the absence
> of `module-info.java` files to avoid several IDE and testing related
> headaches.
>
>  Added
>
> * Added `asciidoc` and `constants-tmpl-adoc` profiles to
>   generate AsciiDoc-based websites from `src/site`
> * Added support to auto-generate changelog entries for
>   `dependabot` updates
> * Added `bnd-maven-plugin` defaults to auto-generate both
>   OSGi and JPMS descriptors
> * Started publishing the project website[1]
>
>  Changed
>
> * Switched the default `log4j-changelog` configuration from
>   Markdown (`.release-notes.md.ftl` and `.index.md.ftl`) to
>   AsciiDoc (`.release-notes.adoc.ftl` and `.index.adoc.ftl`)
> * Update `actions/checkout` to version `4.1.0`
> * Update `com.github.spotbugs:spotbugs-maven-plugin`
>   to version `4.7.3.6`
> * Update `com.google.errorprone:error_prone_core` to
>   version `2.22.0`
> * Update `org.osgi:osgi.annotation` to version `8.1.0`
>
>  Removed
>
> * Removed `project.build.outputTimestamp` override since
>   it is already provided by the parent POM and its old value
>   `0` was causing reproducibility issues[2] for
>   `spring-boot:repackage`
>
> [2] https://github.com/spring-projects/spring-boot/pull/37438
>
>  Fixed
>
> * Replaced incorrect `java.version` Maven property override
>   with `maven.compiler.{source,release,target}`
>

[ANNOUNCE] Apache Logging Parent 10.1.0 released

[Volkan Yazıcı]

Apache Logging Parent team is pleased to announce the 10.1.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].

[1] https://logging.apache.org/logging-parent

=== Release Notes

This minor release focuses on shipping AsciiDoc-based website
generation convenience targeting the `src/site` folder. As a part of
this effort, `logging-parent` started publishing its own website[1]
and `log4j-changelog` support switched from Markdown to AsciiDoc.

The introduced `bnd-maven-plugin`[2] default auto-generates both OSGi
and JPMS descriptors. Users only need to annotate packages that are to
be exported with `org.osgi.annotation.bundle.Export`, plugin will do
the rest of the magic. Hence, no need for custom `.bnd` and/or
`module-info.java` files anymore. In particular, we expect the absence
of `module-info.java` files to avoid several IDE and testing related
headaches.

[2] https://github.com/bndtools/bnd/blob/master/maven-plugins/bnd-maven-plugin

 Added

* Added `asciidoc` and `constants-tmpl-adoc` profiles to
  generate AsciiDoc-based websites from `src/site`
* Added support to auto-generate changelog entries for
  `dependabot` updates
* Added `bnd-maven-plugin` defaults to auto-generate both
  OSGi and JPMS descriptors
* Added CI report uploading in case of test or reproducibility failures
* Started publishing the project website

 Changed

* Switched the default `log4j-changelog` configuration from
  Markdown (`.release-notes.md.ftl` and `.index.md.ftl`) to
  AsciiDoc (`.release-notes.adoc.ftl` and `.index.adoc.ftl`)
* Update `actions/checkout` to version `4.1.0`
* Update `com.github.spotbugs:spotbugs-maven-plugin` to
  version `4.7.3.6`
* Update `com.google.errorprone:error_prone_core` to version
  `2.22.0`
* Update `org.apache:apache` to version `30`
* Update `org.osgi:osgi.annotation` to version `8.1.0`

 Removed

* Removed `project.build.outputTimestamp` override since it is
  already provided by the parent POM and its old value `0`
  was causing reproducibility issues[3] for `spring-boot:repackage`

[3] https://github.com/spring-projects/spring-boot/pull/37438

 Fixed

* Replaced incorrect `java.version` Maven property override
  with `maven.compiler.{source,release,target}`

[VOTE] Release Apache Log4j Kotlin API 1.3.0

[Volkan Yazıcı]

This is a vote to release the Apache Log4j Kotlin API 1.3.0.

Source repository: https://github.com/apache/logging-log4j-kotlin
Commit: b273cfb450898f079d2fd10b575330bfb900101b
Distribution: https://dist.apache.org/repos/dist/dev/logging/log4j-kotlin
Nexus: https://repository.apache.org/content/repositories/orgapachelogging-1186
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. At least 3 +1 votes and more
positive than negative votes are required.

=== Release Notes

This minor release bumps the Kotlin baseline to 1.6.21 and contains
various small improvements.

 Added

* Added an extension property for storing a cached logger (#29)
* Added facade APIs for manipulating the context map and stack (#30)
* Added missing `catching` and `throwing` API methods in `KotlinLogger` (#32)
* Added JPMS support and used `org.apache.logging.log4j.api_kotlin`
for the module name (identical to OSGi `Bundle-SymbolicName`) of the
`log4j-api-kotlin` artifact

 Changed

* Updated Log4j dependency to `2.20.0`
* Bumped `logging-parent` version to `10.1.0` and overhauled the
entire project infrastructure to take advantage of its goodies (#37)
* Renamed OSGi `Bundle-SymbolicName` from
`org.apache.logging.log4j.kotlin` to
`org.apache.logging.log4j.api_kotlin`
* Migrated tests to JUnit 5
* Bumped Kotlin and Kotlin Extensions baseline to `1.6.21` and `1.6.4`
respectively

Re: Archiving `logging-log4j-server` and `-audit`

[Ralph Goers]

Log4j Server receives messages from a Socket Appender. In the past these events 
were serialized using Java Serialization, which was a huge security hole. I 
believe we no longer support that. But the Server has to align its 
serialization scheme with how the appender is sending it. User’s may also 
require authentication or some mechanism to limit access to the service. 
Finally, it is almost certain that the service will need to be modified to take 
whatever actions the user wants on the log events.

For those reasons we kept log4j-server around but aren’t releasing it.  It is 
considered to be a sample for user’s to start from.

Ralph

> On Sep 26, 2023, at 1:49 PM, Christian Grobmeier  wrote:
> 
> Hi,
> 
> what is the purpose of log4j-server actually?
> I don't find any information about it.
> 
> I wonder, if this has a real use case (Gary uses it) but no releases, should 
> we create a Sandbox/Lab?
> Personally, if this just for example purposes, we maybe should actually move 
> it -samples as suggested below.
> 
> This thread is 8 days old, probably it is safe to move this repo now - we can 
> always -1 a commit if there is still an objection
> 
> Kind regards,
> Christian
> 
> 
> On Mon, Sep 18, 2023, at 10:09, Volkan Yazıcı wrote:
>> Hey Gary,
>> 
>> I'd appreciate your response on this `dev@` thread. I am cleaning up all
>> repositories and trying to either (in order of preference)
>> 
>>   1. delete them (since they are practically empty or irrelevant)
>>   2. archive them (clearly communicate it to the users that nobody is
>>   working on these projects, they are not maintained, etc. the repository is
>>   there only for archival purposes. note the archival is a reversible
>>   operation.)
>>   3. modernize them (make `./mvnw clean verify` work flawlessly on
>>   multiple platforms, erect the CI, updated dependencies, setup `dependabot`,
>>   clean up `pom.xml`s, docs, `README.adoc`, etc.)
>> 
>> From this point of view, we (Ralph, Piotr, and me) are in favor of
>> archiving `logging-log4j-server` and moving the `log4j-server` module to
>> `logging-log4j-samples`, which is completely modernized. Is that okay with
>> you?
>> 
>> 
>> On Thu, Sep 14, 2023 at 8:25 PM Volkan Yazıcı  wrote:
>> 
>>> Gary, you haven't replied to this question of mine yet. I'd like to
>>> know more about your use case.
>>> 
>>> I had a call with Ralph and he stated `log4j-server` is not usable
>>> without customizations. Hence, he added, it is better suited to
>>> `log4j-samples`. I liked this idea. Do you have any objections if we
>>> archive the `log4j-server` and move its content to `log4j-samples`
>>> instead?
>>> 
>>> On Wed, Sep 13, 2023 at 3:16 PM Volkan Yazıcı  wrote:
 
 The project doesn't have any releases, how do you use it at work? Note
>>> that once they are retired (i.e., archived) you will still have access to
>>> the sources.
 
 On Wed, Sep 13, 2023 at 3:06 PM Gary Gregory 
>>> wrote:
> 
> Yes, we use logging-log4j-server at work.
> 
> Gary
> 
> On Wed, Sep 13, 2023 at 8:15 AM Volkan Yazıcı  wrote:
>> 
>> I propose retiring `logging-log4j-server`
>>  and
>>> `logging-log4j-audit`
>>  repositories (which
>>> never
>> had any releases) and making it clear in their READMEs that these
>> repositories exist only for archival purposes. Objections?
>>> 

Re: `logging-parent` website

[Ralph Goers]

Why does log4j-parent need a web site?  Why isn’t there README in the Git repo 
enough?

Ralph

> On Sep 26, 2023, at 2:12 PM, Matt Sicker  wrote:
> 
> You can add an asf-site (and asf-staging) branch to logging-parent to get a 
> website published. You can create a branch in git without any commits in its 
> history to start it.
> —
> Matt Sicker
> 
>> On Sep 26, 2023, at 14:00, Volkan Yazıcı  wrote:
>> 
>> *Summary:* I want to place the website of `logging-parent` to `
>> logging.apache.org/parent` served from a to-be-created
>> `logging-parent-site` repository. Objections?
>> 
>> `logging-parent` version `10.1.0` is ready to be released with plenty of
>> features. I want it to play a role model for the rest of the Maven-based
>> Logging Services projects in terms of how its artifacts, distribution, and
>> website is deployed. Though the last bit, "website", is missing. Since
>> `10.1.0` includes plenty of documentation, I have converted it to a
>> website: checkout the `main` branch of `logging-parent` and try `./mvnw
>> site && python -m http.server -d target/site`.
>> 
>> Note for Ralph and for those interested: No, this is not the Antora website
>> combining multiple websites, etc. This is plain `maven-asciidoc-plugin`
>> execution against a bunch of AsciiDoc files under `src/site`. The same is
>> already practiced in `log4j-scala` and `log4j-kotlin` too. I want to adopt
>> this in `log4j-tools` and `log4j-transform` as well.
> 

Re: Migrating the landing page

[Ralph Goers]

I don’t mind AsciiDoc but I have had a few things I couldn’t format with 
AsciiDoc. I am not really sure why AsciiDoc is preferred over Markdown. The 
only problem I have had with Markdown is that some tools don’t support some of 
the latest features.

Ralph

> On Sep 26, 2023, at 2:23 PM, Matt Sicker  wrote:
> 
> Infra supports publishing any sort of site output as long as it’s published 
> via committing to either subversion or git. For git, this is via the normal 
> asf-site and asf-staging branches similar to ghpages branches on GitHub. 
> Since we can set up GitHub Actions to commit to those branches, we can 
> support any static site generator that can be invoked from an Action.
> 
> Given Volkan’s argument around JBake, I agree that it would be the easiest 
> thing to use. Site generators based on Python or Ruby tend to ossify around a 
> bunch of random dependencies thanks to the clusterfuck that is Python and 
> Ruby package management which is somehow only slightly less bad than the C 
> and C++ ecosystem.
> 
> Also agreed on AsciiDoc; Volkan’s reasoning here is exactly why I migrated 
> various documentation to AsciiDoc here in the past. When we first used XDoc, 
> this was an annoying mix of XML and XHTML where our files typically didn’t 
> even validate under the referenced XSDs. I had initially migrated those files 
> to Markdown, but I had to use HTML occasionally. AsciiDoc was the first 
> markup format that didn’t require these escape valves, and they theoretically 
> support template variables, too, so there’s no need to run them through a 
> preprocessor.
> —
> Matt Sicker
> 
>> On Sep 25, 2023, at 04:20, Volkan Yazıcı  wrote:
>> 
>> Great initiative to revamp the Logging Services landing page! Go for it!
>> But don't change JBake and stick to AsciiDoc, please.
>> 
>> *Summary:*
>> 
>>  1. JBake is great, reproducible, and familiar
>>  2. "INFRA support" is not a valid argument
>>  3. Markdown is a dead end
>>  4. The future should ideally not be individual websites
>> 
>> *JBake is feature-wise on par with alternatives*
>> 
>> There are a plethora of static site generators; Jekyll, Pelican, Hugo,
>> JBake, etc. Almost every language ecosystem has its own take on it. But
>> they all boil down to a couple of basic conveniences:
>> 
>>  - pick a typesetting format of your preference (AsciiDoc, Markdown, etc.)
>>  - generate pages with a templating engine of your preference (Velocity,
>>  FreeMarker, Handlebars, etc.)
>>  - compile it to a bunch of static HTML files
>> 
>> Some even include batteries:
>> 
>>  - built-in plugins (sitemap, tagging/labeling, search, etc.)
>>  - preview (so you don't even need an HTTP server of yours)
>>  - hot reload (so you don't need to compile it manually every time)
>> 
>> JBake excels in all these areas.
>> 
>>> docker run --rm -p 4000:4000 --mount type=bind,src=$PWD,dst=/root/build
>> --mount type=volume,dst=/root/build/node_modules -it
>> apache/privacy_apache_org serve --watch --incremental
>> 
>> Uh... That hurts. This is how you can achieve the same in JBake: `./mvnw
>> jbake:watch`.
>> 
>> *The unspoken killer feature: reproducibility*
>> 
>> I have been tinkering with static site generators for more than a decade –
>> I love them. I don't know of your experience, but anything beyond Java
>> sucks a big time when it comes to reproducibility. You cannot run a Ruby
>> application written 10 years ago on a modern operating system. Many Ruby
>> libraries depend on system libraries that either are not shipped with the
>> distro anymore or broke the ABI in the past. I need to use this
>> hand-crafted `Dockerfile`
>>  running on
>> Ubuntu `14.04` with a particular constellation of Ruby dependencies so that
>> I can install a version of `nanoc` that compiles my website. It is an
>> operational nightmare.
>> 
>> But let's talk about Java and JBake: `./mvnw jbake:watch`. This only
>> requires the host to have a decent OS, shell, and JDK. That is all. No
>> more, no less. Docker? Nah. Python? Nah. Some weird OS package? Nah. I can
>> confidently say this command will highly likely run without a single line
>> of change for several decades. Given its historical track record, I don't
>> think any other alternative can beat Java in this area and it is of
>> uttermost importance given how hard it is for the PMC to afford time on the
>> website.
>> 
>> *The argument of familiarity*
>> 
>> 90% of Logging Services committers are Java developers. That is where our
>> expertise lies in. If you throw at them a `pom.xml` and a bunch of AsciiDoc
>> files in `src/site/asciidoc`, without blinking an eye, they would correctly
>> guess what to do. Moving away from this safe zone to uncharted territories,
>> in particular, without factually justifying the rationale, will simply do
>> more harm than benefit, if there is any at all.
>> 
>> *The argument of "INFRA supports Jekyll and Pelican"*
>> 
>> What does that suppor

Re: [VOTE] Move Chainsaw to dormant status

[Ralph Goers]

I will echo Scott’s vote. -1

Ralph

> On Sep 22, 2023, at 7:30 AM, Scott Deboy  wrote:
> 
> -1
> 
> While changes may be infrequent, the project is still useful and works
> well. I'll continue to contribute to maintenance.
> 
> Scott
> 
> On Thu, Sep 21, 2023, 10:00 AM Volkan Yazıcı  wrote:
> 
>> As earlier discussions[1] indicate, Chainsaw has been lacking on
>> maintenance and no PMC member stepped up to perform necessary chores.
>> This is a vote to retire the Chainsaw by means of
>> 
>> - Move it to the list of dormant projects[2]
>> - Making it clear in its README and website that the project is not
>> maintained anymore
>> - Archive its repository[3]
>> 
>> Please cast your votes on this mailing list.
>> 
>> [ ] +1, retire the project
>> [ ] -1, don't retire, 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,
>> but only the Logging Services PMC votes are officially counted. At
>> least 3 +1 votes and more positive than negative votes are required.
>> 
>> [1] https://lists.apache.org/thread/fsykp5hxr9z0c2h85snnhnj2pq553t6q
>> [2] https://logging.apache.org/dormant.html
>> [3] https://github.com/apache/chainsaw
>> 

Re: Migrating the landing page

[Matt Sicker]

AsciiDoc offers syntax for most of the things that Markdown requires you to use 
raw HTML for. Also, the default output format for AsciiDoc looks a lot nicer 
than Markdown, but that’s always customizable.

> On Sep 28, 2023, at 10:35 AM, Ralph Goers  wrote:
> 
> I don’t mind AsciiDoc but I have had a few things I couldn’t format with 
> AsciiDoc. I am not really sure why AsciiDoc is preferred over Markdown. The 
> only problem I have had with Markdown is that some tools don’t support some 
> of the latest features.
> 
> Ralph
> 
>> On Sep 26, 2023, at 2:23 PM, Matt Sicker  wrote:
>> 
>> Infra supports publishing any sort of site output as long as it’s published 
>> via committing to either subversion or git. For git, this is via the normal 
>> asf-site and asf-staging branches similar to ghpages branches on GitHub. 
>> Since we can set up GitHub Actions to commit to those branches, we can 
>> support any static site generator that can be invoked from an Action.
>> 
>> Given Volkan’s argument around JBake, I agree that it would be the easiest 
>> thing to use. Site generators based on Python or Ruby tend to ossify around 
>> a bunch of random dependencies thanks to the clusterfuck that is Python and 
>> Ruby package management which is somehow only slightly less bad than the C 
>> and C++ ecosystem.
>> 
>> Also agreed on AsciiDoc; Volkan’s reasoning here is exactly why I migrated 
>> various documentation to AsciiDoc here in the past. When we first used XDoc, 
>> this was an annoying mix of XML and XHTML where our files typically didn’t 
>> even validate under the referenced XSDs. I had initially migrated those 
>> files to Markdown, but I had to use HTML occasionally. AsciiDoc was the 
>> first markup format that didn’t require these escape valves, and they 
>> theoretically support template variables, too, so there’s no need to run 
>> them through a preprocessor.
>> —
>> Matt Sicker
>> 
>>> On Sep 25, 2023, at 04:20, Volkan Yazıcı  wrote:
>>> 
>>> Great initiative to revamp the Logging Services landing page! Go for it!
>>> But don't change JBake and stick to AsciiDoc, please.
>>> 
>>> *Summary:*
>>> 
>>> 1. JBake is great, reproducible, and familiar
>>> 2. "INFRA support" is not a valid argument
>>> 3. Markdown is a dead end
>>> 4. The future should ideally not be individual websites
>>> 
>>> *JBake is feature-wise on par with alternatives*
>>> 
>>> There are a plethora of static site generators; Jekyll, Pelican, Hugo,
>>> JBake, etc. Almost every language ecosystem has its own take on it. But
>>> they all boil down to a couple of basic conveniences:
>>> 
>>> - pick a typesetting format of your preference (AsciiDoc, Markdown, etc.)
>>> - generate pages with a templating engine of your preference (Velocity,
>>> FreeMarker, Handlebars, etc.)
>>> - compile it to a bunch of static HTML files
>>> 
>>> Some even include batteries:
>>> 
>>> - built-in plugins (sitemap, tagging/labeling, search, etc.)
>>> - preview (so you don't even need an HTTP server of yours)
>>> - hot reload (so you don't need to compile it manually every time)
>>> 
>>> JBake excels in all these areas.
>>> 
 docker run --rm -p 4000:4000 --mount type=bind,src=$PWD,dst=/root/build
>>> --mount type=volume,dst=/root/build/node_modules -it
>>> apache/privacy_apache_org serve --watch --incremental
>>> 
>>> Uh... That hurts. This is how you can achieve the same in JBake: `./mvnw
>>> jbake:watch`.
>>> 
>>> *The unspoken killer feature: reproducibility*
>>> 
>>> I have been tinkering with static site generators for more than a decade –
>>> I love them. I don't know of your experience, but anything beyond Java
>>> sucks a big time when it comes to reproducibility. You cannot run a Ruby
>>> application written 10 years ago on a modern operating system. Many Ruby
>>> libraries depend on system libraries that either are not shipped with the
>>> distro anymore or broke the ABI in the past. I need to use this
>>> hand-crafted `Dockerfile`
>>>  running on
>>> Ubuntu `14.04` with a particular constellation of Ruby dependencies so that
>>> I can install a version of `nanoc` that compiles my website. It is an
>>> operational nightmare.
>>> 
>>> But let's talk about Java and JBake: `./mvnw jbake:watch`. This only
>>> requires the host to have a decent OS, shell, and JDK. That is all. No
>>> more, no less. Docker? Nah. Python? Nah. Some weird OS package? Nah. I can
>>> confidently say this command will highly likely run without a single line
>>> of change for several decades. Given its historical track record, I don't
>>> think any other alternative can beat Java in this area and it is of
>>> uttermost importance given how hard it is for the PMC to afford time on the
>>> website.
>>> 
>>> *The argument of familiarity*
>>> 
>>> 90% of Logging Services committers are Java developers. That is where our
>>> expertise lies in. If you throw at them a `pom.xml` and a bunch of AsciiDoc
>>> files in `src/si

Re: [VOTE] Release Apache Log4j Kotlin API 1.3.0

[Matt Sicker]

+1

> On Sep 28, 2023, at 8:26 AM, Volkan Yazıcı  wrote:
> 
> This is a vote to release the Apache Log4j Kotlin API 1.3.0.
> 
> Source repository: https://github.com/apache/logging-log4j-kotlin
> Commit: b273cfb450898f079d2fd10b575330bfb900101b
> Distribution: https://dist.apache.org/repos/dist/dev/logging/log4j-kotlin
> Nexus: 
> https://repository.apache.org/content/repositories/orgapachelogging-1186
> 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. At least 3 +1 votes and more
> positive than negative votes are required.
> 
> === Release Notes
> 
> This minor release bumps the Kotlin baseline to 1.6.21 and contains
> various small improvements.
> 
>  Added
> 
> * Added an extension property for storing a cached logger (#29)
> * Added facade APIs for manipulating the context map and stack (#30)
> * Added missing `catching` and `throwing` API methods in `KotlinLogger` (#32)
> * Added JPMS support and used `org.apache.logging.log4j.api_kotlin`
> for the module name (identical to OSGi `Bundle-SymbolicName`) of the
> `log4j-api-kotlin` artifact
> 
>  Changed
> 
> * Updated Log4j dependency to `2.20.0`
> * Bumped `logging-parent` version to `10.1.0` and overhauled the
> entire project infrastructure to take advantage of its goodies (#37)
> * Renamed OSGi `Bundle-SymbolicName` from
> `org.apache.logging.log4j.kotlin` to
> `org.apache.logging.log4j.api_kotlin`
> * Migrated tests to JUnit 5
> * Bumped Kotlin and Kotlin Extensions baseline to `1.6.21` and `1.6.4`
> respectively

Re: [VOTE] Move Chainsaw to dormant status

[Gary Gregory]

Might as well cast my official -1.

Gary

On Thu, Sep 28, 2023, 11:37 AM Ralph Goers 
wrote:

> I will echo Scott’s vote. -1
>
> Ralph
>
> > On Sep 22, 2023, at 7:30 AM, Scott Deboy  wrote:
> >
> > -1
> >
> > While changes may be infrequent, the project is still useful and works
> > well. I'll continue to contribute to maintenance.
> >
> > Scott
> >
> > On Thu, Sep 21, 2023, 10:00 AM Volkan Yazıcı  wrote:
> >
> >> As earlier discussions[1] indicate, Chainsaw has been lacking on
> >> maintenance and no PMC member stepped up to perform necessary chores.
> >> This is a vote to retire the Chainsaw by means of
> >>
> >> - Move it to the list of dormant projects[2]
> >> - Making it clear in its README and website that the project is not
> >> maintained anymore
> >> - Archive its repository[3]
> >>
> >> Please cast your votes on this mailing list.
> >>
> >> [ ] +1, retire the project
> >> [ ] -1, don't retire, 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,
> >> but only the Logging Services PMC votes are officially counted. At
> >> least 3 +1 votes and more positive than negative votes are required.
> >>
> >> [1] https://lists.apache.org/thread/fsykp5hxr9z0c2h85snnhnj2pq553t6q
> >> [2] https://logging.apache.org/dormant.html
> >> [3] https://github.com/apache/chainsaw
> >>
>
>

Re: Migrating the landing page

[Christian Grobmeier]

Hello,

I have had a talk with Volkan over the topic and felt that I did not explain my 
cause very well.
I would like to try again.

On Tue, Sep 26, 2023, at 23:23, Matt Sicker wrote:
> Infra supports publishing any sort of site output as long as it’s 
> published via committing to either subversion or git. For git, this is 
> via the normal asf-site and asf-staging branches similar to ghpages 
> branches on GitHub. Since we can set up GitHub Actions to commit to 
> those branches, we can support any static site generator that can be 
> invoked from an Action.

Yes it is possible, but it is not as easy as this:
https://github.com/apache/privacy-website/blob/main/.asf.yaml

>
> Given Volkan’s argument around JBake, I agree that it would be the 
> easiest thing to use. Site generators based on Python or Ruby tend to 
> ossify around a bunch of random dependencies thanks to the clusterfuck 
> that is Python and Ruby package management which is somehow only 
> slightly less bad than the C and C++ ecosystem.

Honestly, I have been using Jekyll for many years and I have never had any 
problems.

If you don't want to mess up your system, I have made a Docker file. So you are 
safe and don't have to deal with any package management.

You can also install Jekyll as a binary and that works extraordinary well. No 
package management needed

In that case, you would to have to run:

jekyll s


You don't need Docker, just install it using brew (or whatever).

>
> Also agreed on AsciiDoc; Volkan’s reasoning here is exactly why I 
> migrated various documentation to AsciiDoc here in the past. 

Jekyll supports AsciiDoc as well, using this plugin:
https://github.com/asciidoctor/jekyll-asciidoc

JBake is a limited system to me and definitely not the easiest solution.
It does not support SCSS and also does not support Data files.
https://jekyllrb.com/docs/datafiles/

Jekyll is the standard for Github pages and has proven to be very stable. It 
has a big community and is operated by blogs all over the world. It has a very 
specific way of doing things and is pretty much a no-brainer for developing. 

For me, JBake's only benefit is you run it using Maven.
It will cost me a lot more time to update it so it is doing the job.
And in some cases, as SCSS it just doesn't work, so I have to use old-school 
CSS for layout changes.

Also, we only have 1 single page that uses AsciiDoc. This page is the team 
page. This page should actually not be maintained as AsciiDoc table, but it 
should be a data file and generate nice HTML.

I am surprised that there is such strong support for JBake, for this always was 
a niche tool (and still is).

That said, I want to achieve one goal quickly: I would like to see the 
news/blog section in a format that is nice to make those announcements, 
including publishing the deprecation plan.

Since I seem to be the only person currently driving this forward, I still 
would like to have the PMCs blessing to move to Jekyll. If you are still not OK 
after what I did, we can roll back to JBake and spend the extra hours 
rebuilding.

Please let me know if any of you is actually a -1, then I save the effort. 
However, I would be very unhappy to spend more time than anticipated working on 
JBake.

Kind regards,
Christian


> —
> Matt Sicker
>
>> On Sep 25, 2023, at 04:20, Volkan Yazıcı  wrote:
>> 
>> Great initiative to revamp the Logging Services landing page! Go for it!
>> But don't change JBake and stick to AsciiDoc, please.
>> 
>> *Summary:*
>> 
>>   1. JBake is great, reproducible, and familiar
>>   2. "INFRA support" is not a valid argument
>>   3. Markdown is a dead end
>>   4. The future should ideally not be individual websites
>> 
>> *JBake is feature-wise on par with alternatives*
>> 
>> There are a plethora of static site generators; Jekyll, Pelican, Hugo,
>> JBake, etc. Almost every language ecosystem has its own take on it. But
>> they all boil down to a couple of basic conveniences:
>> 
>>   - pick a typesetting format of your preference (AsciiDoc, Markdown, etc.)
>>   - generate pages with a templating engine of your preference (Velocity,
>>   FreeMarker, Handlebars, etc.)
>>   - compile it to a bunch of static HTML files
>> 
>> Some even include batteries:
>> 
>>   - built-in plugins (sitemap, tagging/labeling, search, etc.)
>>   - preview (so you don't even need an HTTP server of yours)
>>   - hot reload (so you don't need to compile it manually every time)
>> 
>> JBake excels in all these areas.
>> 
>>> docker run --rm -p 4000:4000 --mount type=bind,src=$PWD,dst=/root/build
>> --mount type=volume,dst=/root/build/node_modules -it
>> apache/privacy_apache_org serve --watch --incremental
>> 
>> Uh... That hurts. This is how you can achieve the same in JBake: `./mvnw
>> jbake:watch`.
>> 
>> *The unspoken killer feature: reproducibility*
>> 
>> I have been tinkering with static site generators for more than a decade –
>> I love them. I don't know of your experience, but anything beyond Java
>> su

Re: Migrating the landing page

[Christian Grobmeier]

On Thu, Sep 28, 2023, at 18:26, Matt Sicker wrote:
> AsciiDoc offers syntax for most of the things that Markdown requires 
> you to use raw HTML for. Also, the default output format for AsciiDoc 
> looks a lot nicer than Markdown, but that’s always customizable.

The output highly depends on the processor. 

AsciiDoc is feature-rich, but also not as widely adopted as Markdown. It is 
also more complex, due to the high number of features. 

I am using Markdown for everything that is lightweight, such as blogs, READMEs, 
or notes because of it's simplicity.
I am using AsciiDoc for technical documentation, books, and anything else that 
requires complex structuring.
(this is not rhetorical, I am actually writing my current book in AsciiDoc)

I don't think Markdown should be dismissed so easily. I would underestimate how 
quick people are to help contribute with Markdown formats compared to AsciiDoc.

For the landing page, I don't think we actually require AsciiDoc, but if this 
is the only blocker, we use the Jekyll plugin for AsciiDoc (provided by the 
AsciiDoc team)

Kind regards,
Christian

>
>> On Sep 28, 2023, at 10:35 AM, Ralph Goers  wrote:
>> 
>> I don’t mind AsciiDoc but I have had a few things I couldn’t format with 
>> AsciiDoc. I am not really sure why AsciiDoc is preferred over Markdown. The 
>> only problem I have had with Markdown is that some tools don’t support some 
>> of the latest features.
>> 
>> Ralph
>> 
>>> On Sep 26, 2023, at 2:23 PM, Matt Sicker  wrote:
>>> 
>>> Infra supports publishing any sort of site output as long as it’s published 
>>> via committing to either subversion or git. For git, this is via the normal 
>>> asf-site and asf-staging branches similar to ghpages branches on GitHub. 
>>> Since we can set up GitHub Actions to commit to those branches, we can 
>>> support any static site generator that can be invoked from an Action.
>>> 
>>> Given Volkan’s argument around JBake, I agree that it would be the easiest 
>>> thing to use. Site generators based on Python or Ruby tend to ossify around 
>>> a bunch of random dependencies thanks to the clusterfuck that is Python and 
>>> Ruby package management which is somehow only slightly less bad than the C 
>>> and C++ ecosystem.
>>> 
>>> Also agreed on AsciiDoc; Volkan’s reasoning here is exactly why I migrated 
>>> various documentation to AsciiDoc here in the past. When we first used 
>>> XDoc, this was an annoying mix of XML and XHTML where our files typically 
>>> didn’t even validate under the referenced XSDs. I had initially migrated 
>>> those files to Markdown, but I had to use HTML occasionally. AsciiDoc was 
>>> the first markup format that didn’t require these escape valves, and they 
>>> theoretically support template variables, too, so there’s no need to run 
>>> them through a preprocessor.
>>> —
>>> Matt Sicker
>>> 
 On Sep 25, 2023, at 04:20, Volkan Yazıcı  wrote:
 
 Great initiative to revamp the Logging Services landing page! Go for it!
 But don't change JBake and stick to AsciiDoc, please.
 
 *Summary:*
 
 1. JBake is great, reproducible, and familiar
 2. "INFRA support" is not a valid argument
 3. Markdown is a dead end
 4. The future should ideally not be individual websites
 
 *JBake is feature-wise on par with alternatives*
 
 There are a plethora of static site generators; Jekyll, Pelican, Hugo,
 JBake, etc. Almost every language ecosystem has its own take on it. But
 they all boil down to a couple of basic conveniences:
 
 - pick a typesetting format of your preference (AsciiDoc, Markdown, etc.)
 - generate pages with a templating engine of your preference (Velocity,
 FreeMarker, Handlebars, etc.)
 - compile it to a bunch of static HTML files
 
 Some even include batteries:
 
 - built-in plugins (sitemap, tagging/labeling, search, etc.)
 - preview (so you don't even need an HTTP server of yours)
 - hot reload (so you don't need to compile it manually every time)
 
 JBake excels in all these areas.
 
> docker run --rm -p 4000:4000 --mount type=bind,src=$PWD,dst=/root/build
 --mount type=volume,dst=/root/build/node_modules -it
 apache/privacy_apache_org serve --watch --incremental
 
 Uh... That hurts. This is how you can achieve the same in JBake: `./mvnw
 jbake:watch`.
 
 *The unspoken killer feature: reproducibility*
 
 I have been tinkering with static site generators for more than a decade –
 I love them. I don't know of your experience, but anything beyond Java
 sucks a big time when it comes to reproducibility. You cannot run a Ruby
 application written 10 years ago on a modern operating system. Many Ruby
 libraries depend on system libraries that either are not shipped with the
 distro anymore or broke the ABI in the past. I need to use this
 hand-crafted `Dockerfile`
 

Re: `logging-parent` website

[Volkan Yazıcı]

There are several reasons that a single `README.adoc` will not suffice for
`logging-parent`:

   1. It bundles plenty of functionality (reusable CI workflows, profiles
   for creating distributions, maintaining release notes, etc.) that needs to
   be documented.
   2. It is the foundation of the new CI-based release process. Its release
   instructions apply to downstream (`log4j-kotlin`, `log4j-scala`,
   `log4j-tools`, `log4j-transform`, etc.) and documentation associated with
   that better be hosted at a central location rather than being cloned
   everywhere.
   3. I am working on aligning the way repositories generate and publish
   their documentation; `./mvnw site`, AsciiDoc files located under
   `src/site`, Maven profile for populating `src/site/_constants.adoc`, etc.
   This will enable us to automate this generation and publication process.
   `logging-parent` is no exception to that.



On Thu, Sep 28, 2023 at 5:24 PM Ralph Goers 
wrote:

> Why does log4j-parent need a web site?  Why isn’t there README in the Git
> repo enough?
>
> Ralph
>
> > On Sep 26, 2023, at 2:12 PM, Matt Sicker  wrote:
> >
> > You can add an asf-site (and asf-staging) branch to logging-parent to
> get a website published. You can create a branch in git without any commits
> in its history to start it.
> > —
> > Matt Sicker
> >
> >> On Sep 26, 2023, at 14:00, Volkan Yazıcı  wrote:
> >>
> >> *Summary:* I want to place the website of `logging-parent` to `
> >> logging.apache.org/parent`  served
> from a to-be-created
> >> `logging-parent-site` repository. Objections?
> >>
> >> `logging-parent` version `10.1.0` is ready to be released with plenty of
> >> features. I want it to play a role model for the rest of the Maven-based
> >> Logging Services projects in terms of how its artifacts, distribution,
> and
> >> website is deployed. Though the last bit, "website", is missing. Since
> >> `10.1.0` includes plenty of documentation, I have converted it to a
> >> website: checkout the `main` branch of `logging-parent` and try `./mvnw
> >> site && python -m http.server -d target/site`.
> >>
> >> Note for Ralph and for those interested: No, this is not the Antora
> website
> >> combining multiple websites, etc. This is plain `maven-asciidoc-plugin`
> >> execution against a bunch of AsciiDoc files under `src/site`. The same
> is
> >> already practiced in `log4j-scala` and `log4j-kotlin` too. I want to
> adopt
> >> this in `log4j-tools` and `log4j-transform` as well.
> >
>
>

Re: [VOTE] Move Chainsaw to dormant status

[Volkan Yazıcı]

Casting my +1, retire the project, because...[1].

With that, the decision does not pass with 3 binding -1 votes from
Scott, Ralph, Gary and 1 binding +1 from me.

[1] As its one and only active maintainer states, the project's user
base is "very low to non-existent"[2]. No PMC member indicated they
can currently afford time to address its shortcomings[3]. PMC should
make this lack-of-maintenance clear to the public. PMC should focus
its limited development resources on projects that have wider
audiences rather than maintaining features serving to a handful of
privileged (i.e., those who can vote go or no-go for a project)
individuals, where these people/organizations can very well keep on
using/maintaining the product from a fork.

[2] https://lists.apache.org/thread/ovhvs42wfw5kzzywzzjtyzj3gjm4hbt0
[3] https://lists.apache.org/thread/t8pzkm9c4qgmb0fw16bswjs69mckt5wc



On Thu, Sep 21, 2023 at 7:00 PM Volkan Yazıcı  wrote:
>
> As earlier discussions[1] indicate, Chainsaw has been lacking on
> maintenance and no PMC member stepped up to perform necessary chores.
> This is a vote to retire the Chainsaw by means of
>
> - Move it to the list of dormant projects[2]
> - Making it clear in its README and website that the project is not
> maintained anymore
> - Archive its repository[3]
>
> Please cast your votes on this mailing list.
>
> [ ] +1, retire the project
> [ ] -1, don't retire, 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,
> but only the Logging Services PMC votes are officially counted. At
> least 3 +1 votes and more positive than negative votes are required.
>
> [1] https://lists.apache.org/thread/fsykp5hxr9z0c2h85snnhnj2pq553t6q
> [2] https://logging.apache.org/dormant.html
> [3] https://github.com/apache/chainsaw