Re: Delete `logging-log4j-plugins`

[Volkan Yazıcı]

Requested its deletion in INFRA-24986.

On Wed, Sep 13, 2023 at 3:37 PM Volkan Yazıcı  wrote:

> `logging-log4j-plugins` 
> is a practically empty repository created 7 years ago. I want to delete it.
> Objections?
>

[VOTE] Release Apache Log4j JMX GUI 2.21.0

[Volkan Yazıcı]

This is a vote to release the Apache Log4j JMX GUI 2.21.0.

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

# Release Notes

This marks the first release where the Log4j JMX GUI is released
separately from the Log4j itself.

## Changes

### Added

* Project is moved to a new repository[1] with its own release cycle

[1] https://github.com/apache/logging-log4j-jmx-gui

Re: [VOTE] Release Apache Log4j JMX GUI 2.21.0

[Remko Popma]

+1
Remko





> On Sep 14, 2023, at 16:34, Volkan Yazıcı  wrote:
> 
> This is a vote to release the Apache Log4j JMX GUI 2.21.0.
> 
> Source repository: https://github.com/apache/logging-log4j-jmx-gui
> Commit: 35d3021e995393a0f62198c2c65af8b47e42688b
> Distribution: https://dist.apache.org/repos/dist/dev/logging/log4j-jmx-gui
> Nexus: 
> https://repository.apache.org/content/repositories/orgapachelogging-1174
> 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. At least 3 +1 votes and more
> positive than negative votes are required.
> 
> # Release Notes
> 
> This marks the first release where the Log4j JMX GUI is released
> separately from the Log4j itself.
> 
> ## Changes
> 
> ### Added
> 
> * Project is moved to a new repository[1] with its own release cycle
> 
> [1] https://github.com/apache/logging-log4j-jmx-gui

Re: Archive `logging-log4j-boot`

[Matt Sicker]

The point of Log4j Boot was to aid in using the correct dependencies for 
various optional features. As we’ve split those optional features out from core 
into appropriate modules, that makes Log4j Boot moot as the individual modules 
will do what this repo was designed to do for 2.x.

I’d be alright with archiving the repo at this point.

> On Sep 13, 2023, at 5:03 PM, Ralph Goers  wrote:
> 
> As far as I am concerned this is totally up to Matt. He created the repo.
> 
>> On Sep 13, 2023, at 7:00 AM, Piotr P. Karwasz  
>> wrote:
>> 
>> Hi Volkan,
>> 
>> On Wed, 13 Sept 2023 at 15:34, Volkan Yazıcı  wrote:
>>> 
>>> `logging-log4j-boot` , last
>>> touched 6 years ago, is a spin-off from LOG4J2-1775
>>> , where it is stated
>>> that *"The Log4j Boot concept can be superseded by the increased
>>> modularization being done in 3.0. No longer relevant."* I want to archive
>>> this repository. Objections?
>> 
>> I see `log4j-boot` as a possibly light alternative to the logging part
>> of Spring Boot.
> 
> I don’t believe it was ever intended to be an alternative to Spring Boot. 
> Matt seemed to have an idea of using this to create various kinds of 
> QuickStarts for various types of applications. I never quite grasped how he 
> planned to do that.
> 
>> 
>> While configuring a logging backend with most APIs requires just the
>> right dependencies on the classpath, users might still need some
>> programmatic help to configure JUL.
>> 
>> IMHO Log4j Boot could do just that, i.e. check if Logback or Log4j
>> Core are on the classpath and either:
>> * set the appropriate `LogManager` property if it is not too late,
>> * or configure a JUL handler to forward everything to the right API.
>> 
> 
> Yes, Spring Boot does just that.  But doing that in a generic way without any 
> other kind of framework seems impractical to me. But I would be willing to be 
> proved wrong.
> 
> Ralph
> 

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

[Matt Sicker]

And I know there’s a Jenkins plugin based on log4j-audit. We’ve had a couple 
releases so far at least.

> On Sep 13, 2023, at 5:01 PM, Gary Gregory  wrote:
> 
> More than once: https://logging.apache.org/log4j-audit/latest/download.html
> 
> Gary
> 
> On Wed, Sep 13, 2023 at 5:56 PM Ralph Goers  
> wrote:
>> 
>> I am quite sure I have released Log4j-Audit. Yes, I object to archiving it.
>> 
>> Ralph
>> 
>>> On Sep 13, 2023, at 5: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: Silly logging- prefix for artifact names

[Matt Sicker]

Yeah, the logging- prefix is how ASF handles multiple sub-orgs in the ASF org.

> On Sep 13, 2023, at 8:05 AM, Gary Gregory  wrote:
> 
> Can we please drop the silly "logging-" prefix for all our artifacts?
> 
> "logging-log4j-foo"? I always recoil...
> 
> Gary

Re: Migrating `log4j-scala` to Maven

[Matt Sicker]

If those alternative libraries are sufficient facades, then we could consider 
archiving this. Otherwise, we’ll look into modernizing the build for making 
more regular releases again.

> On Sep 13, 2023, at 11:04 AM, PJ Fanning  wrote:
> 
> My view is that in the absence of regular releases and active
> development, log4j-api-scala should be abandoned.
> It is more than 3 years since the 12.0 release of log4j-api-scala. The
> lib does not appear to be commonly used. There are lots of
> alternatives open to Scala developers.
> Slf4j predominates in the Scala community and you can use the Slf4j to
> Log4j bridge if you want to use Log4j as the logging backend.
> 
> scala-logging [1] is a good alternative for anyone who currently uses
> log4j-api-scala.
> 
> [1] https://index.scala-lang.org/lightbend-labs/scala-logging
> 
> On Wed, 13 Sept 2023 at 13:46, Volkan Yazıcı  wrote:
>> 
>> Matt, PJ, shall we migrate `log4j-scala` from sbt to Maven?
>> 
>> `logging-parent` 10.0.0 ships a great deal of convenience for build+release 
>> of Maven-based projects. I have already migrated `logging-parent`, 
>> `log4j-tools`, `log4j-transform`, `log4j-kotlin`, `log4j-jmx-gui` to this 
>> shared infrastructure. Unless we do certain tricks in sbt that are not 
>> possible via Maven, I would like to match `log4j-scala` with the rest by 
>> migrating it to Maven too.

Re: Renamed `master` to `main` for `logging-log4j-kotlin`

[Matt Sicker]

Thanks for handling that

> On Sep 13, 2023, at 6:19 AM, Volkan Yazıcı  wrote:
> 
> INFRA-24976 implements the rename of `master` to `main` for the
> `logging-log4j-kotlin` repository, FYI.

Re: Switch from `maven-bundle-plugin` to `bnd-maven-plugin`

[Matt Sicker]

I’m in favor of using bnd-maven-plugin (as the person who introduced it in 
log4j-api-kotlin) mainly due to the fact that it’s a more first-class OSGi 
project that’s still recommended for modern OSGi development.

> On Sep 13, 2023, at 4:12 AM, Piotr P. Karwasz  wrote:
> 
> Hi,
> 
> As you probably know many of our repos use `maven-bundle-plugin` (from
> Apache Felix) to create an OSGI descriptor for all our artifacts. The
> exception is `log4j-api-kotlin`, which uses `bnd-maven-plugin`.
> 
> We would like to uniformise the building process and switch  to the
> **exception** (`bnd-maven-plugin`) because:
> * both plugins use BND under the hood and `bnd-maven-plugin` is
> released by the same project as BND,
> * `bnd-maven-plugin` has a lifecycle coordinated with BND, so it
> always uses the newest BND version (no need to manage two
> dependencies).
> 
> What do you think about this change?
> 
> Moreover we could think about using BND to generate our JPMS
> descriptors in 3.x. These would be guaranteed to be compatible with
> our OSGI descriptor (see [1] for an example).
> 
> Piotr
> 
> [1] https://github.com/JCTools/JCTools/pull/370

Re: Archive `logging-log4j-boot`

[Piotr P. Karwasz]

Hi Matt,

On Thu, 14 Sept 2023 at 18:58, Matt Sicker  wrote:
>
> The point of Log4j Boot was to aid in using the correct dependencies for 
> various optional features. As we’ve split those optional features out from 
> core into appropriate modules, that makes Log4j Boot moot as the individual 
> modules will do what this repo was designed to do for 2.x.
>
> I’d be alright with archiving the repo at this point.

+1 to that. Moreover INFRA confirmed that archivisation is reversible.

Piotr

Renamed `master` to `main` for `logging-log4j-scala`

[Volkan Yazıcı]

INFRA-24980 implements the rename of `master` to `main` for the
`logging-log4j-scala` repository, FYI.

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

[Volkan Yazıcı]

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?

[log4j-kotlin] Preparing 1.3.0

[Volkan Yazıcı]

I'd like to release `log4j-kotlin` 1.3.0, though one thing still needs
to be decided: Kotlin baseline. I'd like to raise this from `1.3.72`
to `1.6.21`. Thoughts? Objections?

Re: Archive `logging-log4j-boot`

[Volkan Yazıcı]

Created INFRA-24989 requesting archival of `logging-log4j-boot`.

On Wed, Sep 13, 2023 at 3:34 PM Volkan Yazıcı  wrote:
>
> `logging-log4j-boot`, last touched 6 years ago, is a spin-off from 
> LOG4J2-1775, where it is stated that "The Log4j Boot concept can be 
> superseded by the increased modularization being done in 3.0. No longer 
> relevant." I want to archive this repository. Objections?

Re: [log4j-kotlin] Preparing 1.3.0

[Raman Gupta]

On Thu, Sep 14, 2023 at 2:39 PM Volkan Yazıcı  wrote:

> I'd like to release `log4j-kotlin` 1.3.0, though one thing still needs
> to be decided: Kotlin baseline. I'd like to raise this from `1.3.72`
> to `1.6.21`. Thoughts? Objections?
>

I don't have any objections as the current version is 1.9.x and even
supporting 2 versions back, let alone 3, is more than sufficient IMO.
However, do see Matt's comments about this here:
https://github.com/apache/logging-log4j-kotlin/pull/34#issuecomment-1430082484.
I was actually wondering last week whether we could go to the latest 1.7.x.

Regards,
Raman

Re: [log4j-kotlin] Preparing 1.3.0

[Matt Sicker]

I’d have to make sure that I can upgrade Spinnaker to Kotlin 1.6.x, but would 
otherwise be ok with that at this point.

> On Sep 14, 2023, at 1:38 PM, Volkan Yazıcı  wrote:
> 
> I'd like to release `log4j-kotlin` 1.3.0, though one thing still needs
> to be decided: Kotlin baseline. I'd like to raise this from `1.3.72`
> to `1.6.21`. Thoughts? Objections?

Re: Framework for integration tests

[Matt Sicker]

I’ve switched from Docker and Docker Desktop to something new (not Rancher), 
but it does expose Docker compatibility APIs, so not a problem here.

> On Sep 13, 2023, at 4:40 PM, Ralph Goers  wrote:
> 
> Are you really switching from Docker or just Docker Desktop?  We moved to use 
> Rancher due to the licensing problems with Docker Desktop. But that still 
> uses K8S and Docker.
> 
> Ralph
> 
> 
> 
>> On Sep 13, 2023, at 6:13 AM, Gary Gregory  wrote:
>> 
>> FWIW, on my main (work) laptop, I am about to switch away from Docker
>> on the desktop to another container solution (not sure which one yet).
>> 
>> Gary
>> 
>> On Wed, Sep 13, 2023 at 2:33 AM Piotr P. Karwasz
>>  wrote:
>>> 
>>> Hi Volkan,
>>> 
>>> On Wed, 13 Sept 2023 at 08:23, Volkan Yazıcı  wrote:
 Though note that this will introduce a new requirement on the build
 hosts: Docker Engine accessibility. Hence, it is better to put these
 behind a Maven profile (`container`?) that one can opt out of.
>>> 
>>> This is my main concern, do all committers accept tests running on Docker?
>>> At work I have successfully ran Docker with WSL2, but be aware that
>>> this changes the way Windows work and other virtualisation
>>> technologies might need to be reconfigured or will slow down (e.g.
>>> VirtualBox).
>>> 
>>> Piotr
> 

Re: Framework for integration tests

[Gary Gregory]

Podman?

On Thu, Sep 14, 2023, 4:42 PM Matt Sicker  wrote:

> I’ve switched from Docker and Docker Desktop to something new (not
> Rancher), but it does expose Docker compatibility APIs, so not a problem
> here.
>
> > On Sep 13, 2023, at 4:40 PM, Ralph Goers 
> wrote:
> >
> > Are you really switching from Docker or just Docker Desktop?  We moved
> to use Rancher due to the licensing problems with Docker Desktop. But that
> still uses K8S and Docker.
> >
> > Ralph
> >
> >
> >
> >> On Sep 13, 2023, at 6:13 AM, Gary Gregory 
> wrote:
> >>
> >> FWIW, on my main (work) laptop, I am about to switch away from Docker
> >> on the desktop to another container solution (not sure which one yet).
> >>
> >> Gary
> >>
> >> On Wed, Sep 13, 2023 at 2:33 AM Piotr P. Karwasz
> >>  wrote:
> >>>
> >>> Hi Volkan,
> >>>
> >>> On Wed, 13 Sept 2023 at 08:23, Volkan Yazıcı  wrote:
>  Though note that this will introduce a new requirement on the build
>  hosts: Docker Engine accessibility. Hence, it is better to put these
>  behind a Maven profile (`container`?) that one can opt out of.
> >>>
> >>> This is my main concern, do all committers accept tests running on
> Docker?
> >>> At work I have successfully ran Docker with WSL2, but be aware that
> >>> this changes the way Windows work and other virtualisation
> >>> technologies might need to be reconfigured or will slow down (e.g.
> >>> VirtualBox).
> >>>
> >>> Piotr
> >
>
>

Re: Framework for integration tests

[Matt Sicker]

No, some internal thing.

> On Sep 14, 2023, at 3:50 PM, Gary Gregory  wrote:
> 
> Podman?
> 
> On Thu, Sep 14, 2023, 4:42 PM Matt Sicker  wrote:
> 
>> I’ve switched from Docker and Docker Desktop to something new (not
>> Rancher), but it does expose Docker compatibility APIs, so not a problem
>> here.
>> 
>>> On Sep 13, 2023, at 4:40 PM, Ralph Goers 
>> wrote:
>>> 
>>> Are you really switching from Docker or just Docker Desktop?  We moved
>> to use Rancher due to the licensing problems with Docker Desktop. But that
>> still uses K8S and Docker.
>>> 
>>> Ralph
>>> 
>>> 
>>> 
 On Sep 13, 2023, at 6:13 AM, Gary Gregory 
>> wrote:
 
 FWIW, on my main (work) laptop, I am about to switch away from Docker
 on the desktop to another container solution (not sure which one yet).
 
 Gary
 
 On Wed, Sep 13, 2023 at 2:33 AM Piotr P. Karwasz
  wrote:
> 
> Hi Volkan,
> 
> On Wed, 13 Sept 2023 at 08:23, Volkan Yazıcı  wrote:
>> Though note that this will introduce a new requirement on the build
>> hosts: Docker Engine accessibility. Hence, it is better to put these
>> behind a Maven profile (`container`?) that one can opt out of.
> 
> This is my main concern, do all committers accept tests running on
>> Docker?
> At work I have successfully ran Docker with WSL2, but be aware that
> this changes the way Windows work and other virtualisation
> technologies might need to be reconfigured or will slow down (e.g.
> VirtualBox).
> 
> Piotr
>>> 
>> 
>>