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

[Piotr P. Karwasz]

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: Switch from `maven-bundle-plugin` to `bnd-maven-plugin`

[Volkan Yazıcı]

I support all 3 proposals:

   1. using `bnd-maven-plugin`
   2. using it everywhere (i.e., making it a part of `logging-parent`, I
   presume)
   3. using it for JMPS descriptors

Does #3 only need to happen on `3.x`? Can't we implement this for `2.x` too?


On Wed, Sep 13, 2023 at 11:13 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
>

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

[Volkan Yazıcı]

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

[log4j] Kotlin API facelift

[Volkan Yazıcı]

I have landed a facelift PR
 to `log4j-kotlin`.

@Matt, @Raman, could you help me with the review and fixing
the Spotbugs failures, please? (Feel free to push to the `facelift` branch.)

Note that `src/site` is removed and replaced with a simple
`doc/manual.adoc` similar to `log4j-transform`. This necessitates a
`logging-log4j-site` change after merging the PR.

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

[Volkan Yazıcı]

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?

Disabling PRs for `logging-log4j1`

[Volkan Yazıcı]

I want to close the existing PRs on `logging-log4j1`
 and disable PRs for the
repository. Objections?

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

[Gary Gregory]

Hi Piotr,

I'm curious about this change. It seems like a fine idea because of
the match with the underlying bnd tool. Is there another advantage?

Depending on our experience here, I might switch Apache Commons as
well, so I'm interested to how this turns out :-)

Gary

On Wed, Sep 13, 2023 at 5: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: Switch from `maven-bundle-plugin` to `bnd-maven-plugin`

[Gary Gregory]

Speaking of JPMS, you might be interested that over at Apache Commons,
we've started using the Moditect Maven plugin to generate module-info
files automatically (see the parent POM if you're interested).

Gary


On Wed, Sep 13, 2023 at 5:32 AM Volkan Yazıcı  wrote:
>
> I support all 3 proposals:
>
>1. using `bnd-maven-plugin`
>2. using it everywhere (i.e., making it a part of `logging-parent`, I
>presume)
>3. using it for JMPS descriptors
>
> Does #3 only need to happen on `3.x`? Can't we implement this for `2.x` too?
>
>
> On Wed, Sep 13, 2023 at 11:13 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: Disabling PRs for `logging-log4j1`

[Piotr P. Karwasz]

Hi Volkan,

On Wed, 13 Sept 2023 at 14:20, Volkan Yazıcı  wrote:
>
> I want to close the existing PRs on `logging-log4j1`
>  and disable PRs for the
> repository. Objections?

+1

There are also these repos, which we could delete (if possible) or archive:

 * logging--log4j-boot with a typo: no code, delete if possible,
 * log4j-component, log4j-extras, log4j-receivers, log4j-zeroconf all
depend on Log4j 1.x. They should be archived with it (requires a PMC
vote?),

Piotr

Re: Disabling PRs for `logging-log4j1`

[Gary Gregory]

Sounds reasonable.

Gary

On Wed, Sep 13, 2023 at 8:20 AM Volkan Yazıcı  wrote:
>
> I want to close the existing PRs on `logging-log4j1`
>  and disable PRs for the
> repository. Objections?

Migrating `log4j-scala` to Maven

[Volkan Yazıcı]

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: Switch from `maven-bundle-plugin` to `bnd-maven-plugin`

[Piotr P. Karwasz]

Hi Gary,

On Wed, 13 Sept 2023 at 14:41, Gary Gregory  wrote:
>
> Speaking of JPMS, you might be interested that over at Apache Commons,
> we've started using the Moditect Maven plugin to generate module-info
> files automatically (see the parent POM if you're interested).

I have seen you mention it somewhere and it would be interesting to
compare what Moditect can offer that BND can't.

The change to `bnd-maven-plugin` would be mostly motivated by cutting
the middleman (Apache Felix). I can open a test branch to see how it
works.

Piotr

Re: Disabling PRs for `logging-log4j1`

[Volkan Yazıcı]

Created INFRA-24978 for the deletion of `logging--log4j-boot`.

Just being told by INFRA that `apache/log4j-*` repos are not managed by any
PMC . I
will create an INFRA ticket to "freeze" them, if such a thing is possible.

On Wed, Sep 13, 2023 at 2:39 PM Piotr P. Karwasz 
wrote:

> Hi Volkan,
>
> On Wed, 13 Sept 2023 at 14:20, Volkan Yazıcı  wrote:
> >
> > I want to close the existing PRs on `logging-log4j1`
> >  and disable PRs for the
> > repository. Objections?
>
> +1
>
> There are also these repos, which we could delete (if possible) or archive:
>
>  * logging--log4j-boot with a typo: no code, delete if possible,
>  * log4j-component, log4j-extras, log4j-receivers, log4j-zeroconf all
> depend on Log4j 1.x. They should be archived with it (requires a PMC
> vote?),
>
> Piotr
>

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

[Gary Gregory]

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?

Silly logging- prefix for artifact names

[Gary Gregory]

Can we please drop the silly "logging-" prefix for all our artifacts?

"logging-log4j-foo"? I always recoil...

Gary

Re: Silly logging- prefix for artifact names

[Volkan Yazıcı]

Except `logging-parent`, no _artifacts_ are prefixed with `logging-`. Do
you have any particular examples?
If you are referring to repositories, it is an INFRA requirement.

On Wed, Sep 13, 2023 at 3:06 PM Gary Gregory  wrote:

> Can we please drop the silly "logging-" prefix for all our artifacts?
>
> "logging-log4j-foo"? I always recoil...
>
> Gary
>

Re: Framework for integration tests

[Gary Gregory]

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: Silly logging- prefix for artifact names

[Gary Gregory]

Phew! TY for the reminder.

Gary

On Wed, Sep 13, 2023 at 9:13 AM Volkan Yazıcı  wrote:
>
> Except `logging-parent`, no _artifacts_ are prefixed with `logging-`. Do
> you have any particular examples?
> If you are referring to repositories, it is an INFRA requirement.
>
> On Wed, Sep 13, 2023 at 3:06 PM Gary Gregory  wrote:
>
> > Can we please drop the silly "logging-" prefix for all our artifacts?
> >
> > "logging-log4j-foo"? I always recoil...
> >
> > Gary
> >

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

[Volkan Yazıcı]

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: Disabling PRs for `logging-log4j1`

[Volkan Yazıcı]

Created INFRA-24979 for archiving the following repositories:

- `logging-log4j1`
- `log4j-receivers`
- `log4j-extras`
- `log4j-component`
- `log4j-zeroconf`

On Wed, Sep 13, 2023 at 2:20 PM Volkan Yazıcı  wrote:

> I want to close the existing PRs on `logging-log4j1`
>  and disable PRs for the
> repository. Objections?
>

Archive `logging-log4j-boot`

[Volkan Yazıcı]

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

Delete `logging-log4j-plugins`

[Volkan Yazıcı]

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

Re: Archive `logging-log4j-boot`

[Piotr P. Karwasz]

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.

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.

Piotr

Re: Archive `logging-log4j-boot`

[Volkan Yazıcı]

I agree that there is a potential. Though I prefer a clear stance on the
status of a repository: is a thing yet or not? It has been dormant for 7
years already and there is no clear future commitment. Unless somebody is
certain that it will be picked up in a matter of months, I am in favor of
archiving the repository. If it is deemed to be necessary, we can always
activate it later I guess.

On Wed, Sep 13, 2023 at 4:01 PM 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.
>
> 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.
>
> Piotr
>

Re: Migrating `log4j-scala` to Maven

[PJ Fanning]

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: Switch from `maven-bundle-plugin` to `bnd-maven-plugin`

[Ralph Goers]

I am fine with switching to the bed-maven-plugin. It simply may not have 
existed when we first started using the Felix plugin. 

It feels a little strange to generate JPMS descriptors from an OSGI tool, but 
if it works - OK.

Ralph

> On Sep 13, 2023, at 2: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: Framework for integration tests

[Ralph Goers]

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

[Ralph Goers]

I am assuming the CI builds would still run natively as they do now. CI 
workflows for integration tests should be free to use whatever tooling they may 
need. 

Ralph

> On Sep 12, 2023, at 11:33 PM, 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: Silly logging- prefix for artifact names

[Ralph Goers]

It isn’t really INFRA. It is the fact that the ASF is a single GitHub account. 
So the only way to distinguish between projects is via a repo prefix since 
GitHub lacks any other good way of doing it. FWIW - GitHub does have something 
called “Projects”, and it looks like we could create one or more of them, but I 
am not sure it does what you would want and it still would be required to have 
the prefix to be able to identify a project’s repos reliably.

Ralph

> On Sep 13, 2023, at 6:14 AM, Gary Gregory  wrote:
> 
> Phew! TY for the reminder.
> 
> Gary
> 
> On Wed, Sep 13, 2023 at 9:13 AM Volkan Yazıcı  wrote:
>> 
>> Except `logging-parent`, no _artifacts_ are prefixed with `logging-`. Do
>> you have any particular examples?
>> If you are referring to repositories, it is an INFRA requirement.
>> 
>> On Wed, Sep 13, 2023 at 3:06 PM Gary Gregory  wrote:
>> 
>>> Can we please drop the silly "logging-" prefix for all our artifacts?
>>> 
>>> "logging-log4j-foo"? I always recoil...
>>> 
>>> Gary
>>> 

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

[Ralph Goers]

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: Delete `logging-log4j-plugins`

[Ralph Goers]

No objection from me.

Ralph

> On Sep 13, 2023, at 6:37 AM, Volkan Yazıcı  wrote:
> 
> `logging-log4j-plugins` 
> is a practically empty repository created 7 years ago. I want to delete it.
> Objections?

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

[Gary Gregory]

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: Framework for integration tests

[Gary Gregory]

We are switch away from Docker Desktop, the replacement has not been
decided yet, any advice?

Gary

On Wed, Sep 13, 2023 at 5: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: Archive `logging-log4j-boot`

[Ralph Goers]

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: Framework for integration tests

[Ralph Goers]

As I said, we are using Rancher. It has worked pretty well so far.

Ralph

> On Sep 13, 2023, at 3:00 PM, Gary Gregory  wrote:
> 
> We are switch away from Docker Desktop, the replacement has not been
> decided yet, any advice?
> 
> Gary
> 
> On Wed, Sep 13, 2023 at 5: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]

Check, TY!

On Wed, Sep 13, 2023 at 6:06 PM Ralph Goers  wrote:
>
> As I said, we are using Rancher. It has worked pretty well so far.
>
> Ralph
>
> > On Sep 13, 2023, at 3:00 PM, Gary Gregory  wrote:
> >
> > We are switch away from Docker Desktop, the replacement has not been
> > decided yet, any advice?
> >
> > Gary
> >
> > On Wed, Sep 13, 2023 at 5: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
> >>
>