Re: [VOTE] Release log4cxx 1.0.0

[Thorsten Schöning]

Guten Tag Robert Middleton,
am Sonntag, 1. Januar 2023 um 19:06 schrieben Sie:

> Please download, test, and cast your votes on the log4j developers list.
> [] +1, release the artifacts
> [] -1, don't release because...

+1

I've successfully compiled and ran all tests using MS Visual Studio
17.4.3 64 Bit under Windows 10 22H2 19045.2364 64 Bit.

Mit freundlichen Grüßen

Thorsten Schöning

-- 
AM-SoFT IT-Service - Bitstore Hameln GmbH
Mitglied der Bitstore Gruppe - Ihr Full-Service-Dienstleister für IT und TK

E-Mail: thorsten.schoen...@am-soft.de
Web:http://www.AM-SoFT.de/

Tel:   +49 5151-  9468- 0
Tel:   +49 5151-  9468-55
Mobil: +49  178-8 9468-04

AM-SoFT IT-Service - Bitstore Hameln GmbH, Brandenburger Str. 7c, 31789 Hameln
AG Hannover HRB 221853 - Geschäftsführer: Janine Galonska


Für Rückfragen stehe ich Ihnen jederzeit zur Verfügung. 

Mit freundlichen Grüßen, 

Thorsten Schöning


Telefon: +49 5151 9468-55
Fax: 
E-Mail: tschoen...@am-soft.de

AM-Soft IT-Service - Bitstore Hameln GmbH
Brandenburger Straße 7c
31789 Hameln

Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen 
und ist ausschliesslich für den Adressaten bestimmt. Jeglicher Zugriff auf 
diese E-Mail durch andere Personen als den Adressaten ist untersagt. Wenn Sie 
nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, 
informieren Sie bitte sofort den Absender und vernichten Sie diese E-Mail. 
Sollten Sie nicht der für diese E-Mail bestimmte Adressat sein, ist Ihnen jede 
Veröffentlichung, Vervielfältigung oder Weitergabe wie auch das Ergreifen oder 
Unterlassen von Massnahmen im Vertrauen auf erlangte Information untersagt. 

This e-mail may contain confidential and/or privileged information and is 
intended solely for the addressee. Access to this email by anyone else is 
unauthorized. If you are not the intended recipient (or have received this 
e-mail in error) please notify the sender immediately and destroy this e-mail. 
If you are not the intended recipient, any disclosure, copying, distribution or 
any action taken or omitted to be taken in reliance on it, is prohibited and 
may be unlawful. 

Hinweise zum Datenschutz: bitstore.group/datenschutz

Re: [log4cxx] Next steps / release?

[Robert Middleton]

Awesome!  Thanks for the packaging work that you do.  Once we get it
voted on you should have a proper release.

-Robert Middleton

On Mon, Jan 2, 2023 at 2:52 PM Tobias Frost  wrote:
>
> Update:
>
> FTP masters have been very quick and approved the package, so the snapshot is
> already in experimental. [1]
>
> I've also rebuilt all reverse depdencies successfully and asked the release 
> team
> to approve the transition. [2]
>
> [1] https://packages.debian.org/source/experimental/log4cxx
> [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1027746
>
> Cheers,
> --
> tobi
>
> On Sat, Dec 31, 2022 at 10:52:43AM +0100, Tobias Frost wrote:
> > On Thu, Dec 29, 2022 at 05:21:34PM -0500, Robert Middleton wrote:
> >
> > > The last time we talked about this Tobias Frost said that the
> > > soft-freeze for Debian is the 12th of January[1], so after that point
> > > an updated library wouldn't make it into Debian.  I would like to get
> > > this version into Debian if possible(as that is the distribution I
> > > use), but that depends on Tobias' availability.
> >
> > To have a chance to make that happen, I've started the transistion workflow 
> > [1].
> > TBH, due to the soft freeze is in less than two weeks, changes are high that
> > we won't make it, but at least I want to have tried it.
> >
> > The first step is "Upload your new version to experimental (and have it 
> > clear
> > NEW)", which is what I've just have done: I've uploaded a snapshot (commit
> > cbd23ff1) to debian experimental. This needs now to be approved by the 
> > (Debian)
> > ftp masters, which is (usually) for such a change quick, but if they aren't 
> > or
> > not happy for any reason, this can spoil the game. [2]
> >
> > Only after that, I can ask for a transition slot from the release team. If 
> > they are
> > not happy with a transition that late (IOW that short before the freeze), 
> > well
> > that will be something I have to accept and that will mean 1.0.0 not in
> > bookworm.
> >
> > In parallel I'll see if the reverse dependencies are still building with the
> > new version, as for any breakage I will need to have patches available…
> >
> > So, let's see how it works out.
> >
> > [1] if you want to know the details: 
> > https://wiki.debian.org/Teams/ReleaseTeam/Transitions
> > [2] It needs to go through NEW due to the binary package rename, due to the 
> > SONAME bump.
> >
> > --
> > tobi

Re: Log4j Maven plugin

[Ralph Goers]

I think putting it in the tools repo would be fine.

Ralph

> On Jan 2, 2023, at 2:34 PM, Piotr P. Karwasz  wrote:
> 
> Hi,
> 
>> On Mon, 2 Jan 2023 at 10:08, Volkan Yazıcı  wrote:
>> Agreed with the separate repository idea. I suggest moving it to the
>> `logging-log4j-maven-plugins` repository – you need an INFRA ticket to
>> create the repository.
> 
> The Maven plugin will not be the only use-case of the code after I
> finish up the project.
> 
> Since I am really bad at naming things, so maybe I'll describe the
> feature-set and someone will come with the ideal name. :-D
> 
> I imagine one module that will weave bytecode (`log4j-instrument`) to:
> * convert classical Log4j2 API calls to LogBuilder calls with location,
> * convert other API calls (Log4j 1.2, JCL, SLF4J and especially
> `java.util.logging`) to Log4j2 API calls (LogBuilder with location for
> now),
> * implement `java.lang.instrument.ClassFileTransformer` so that we
> can use it to weave at runtime.
> 
> A second module would be based on a refactoring library (Error Prone?
> called `log4j-errorprone`?) to:
> * convert classical Log4j2 API calls to LogBuilder (this simplifies
> weaving a lot),
> * convert other API calls to Log4j2 API,
> * check for common mistakes of new Log4j2 API adopters: e.g. `if
> (logger.isDebugEnabled() logger.debug(...);` or `logger.debug("Hello
> name " + name + ".")`.
> 
> A Maven module would use `log4j-instrument` to:
> * weave a project's classes,
> * weave all JAR dependencies (well, with some default exclusion
> patterns such as `log4j-*.jar` of course),
> * create a POM that only references Log4j2 API.
> 
> And of course Maven is not the only build tool on the market.
> Contributors could submit plugins for other build tools.
> 
> I think that `logging-log4j-tools` would be a nice name for a
> repository, but it is taken. :-) Unless `log4j-changelog` is targeted
> at a larger audience, in which case we can share. :-)
> 
> Piotr

Re: Syncing `master`

[Piotr P. Karwasz]

Hi Volkan,

On Mon, 2 Jan 2023 at 09:50, Volkan Yazıcı  wrote:
> Suggestion: Shall we harness GitHub Actions to create a GitHub Issue
> telling commit X needs to be reflected on branch Y whenever a commit lands
> on branch Z?
>
> If you all agree, I volunteer to set this up.

If you can add a time delay, that would be fantastic.

I imagine some logic like: if 24 hours have passed and the commit with
a subject line "Hello World!" on `release-2.x` does not have a commit
in `master` with the same subject, create an issue. Commits that need
a subject change (like "Deprecate for removal" -> "Remove") are rare
and a committer can always close those issues manually.

Piotr

Re: Log4j Maven plugin

[Piotr P. Karwasz]

Hi,

On Mon, 2 Jan 2023 at 10:08, Volkan Yazıcı  wrote:
> Agreed with the separate repository idea. I suggest moving it to the
> `logging-log4j-maven-plugins` repository – you need an INFRA ticket to
> create the repository.

The Maven plugin will not be the only use-case of the code after I
finish up the project.

Since I am really bad at naming things, so maybe I'll describe the
feature-set and someone will come with the ideal name. :-D

I imagine one module that will weave bytecode (`log4j-instrument`) to:
 * convert classical Log4j2 API calls to LogBuilder calls with location,
 * convert other API calls (Log4j 1.2, JCL, SLF4J and especially
`java.util.logging`) to Log4j2 API calls (LogBuilder with location for
now),
 * implement `java.lang.instrument.ClassFileTransformer` so that we
can use it to weave at runtime.

A second module would be based on a refactoring library (Error Prone?
called `log4j-errorprone`?) to:
 * convert classical Log4j2 API calls to LogBuilder (this simplifies
weaving a lot),
 * convert other API calls to Log4j2 API,
 * check for common mistakes of new Log4j2 API adopters: e.g. `if
(logger.isDebugEnabled() logger.debug(...);` or `logger.debug("Hello
name " + name + ".")`.

A Maven module would use `log4j-instrument` to:
 * weave a project's classes,
 * weave all JAR dependencies (well, with some default exclusion
patterns such as `log4j-*.jar` of course),
 * create a POM that only references Log4j2 API.

And of course Maven is not the only build tool on the market.
Contributors could submit plugins for other build tools.

I think that `logging-log4j-tools` would be a nice name for a
repository, but it is taken. :-) Unless `log4j-changelog` is targeted
at a larger audience, in which case we can share. :-)

Piotr

Re: [log4cxx] Next steps / release?

[Tobias Frost]

Update:

FTP masters have been very quick and approved the package, so the snapshot is
already in experimental. [1]

I've also rebuilt all reverse depdencies successfully and asked the release team
to approve the transition. [2]

[1] https://packages.debian.org/source/experimental/log4cxx
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1027746

Cheers,
--
tobi 

On Sat, Dec 31, 2022 at 10:52:43AM +0100, Tobias Frost wrote:
> On Thu, Dec 29, 2022 at 05:21:34PM -0500, Robert Middleton wrote:
> 
> > The last time we talked about this Tobias Frost said that the
> > soft-freeze for Debian is the 12th of January[1], so after that point
> > an updated library wouldn't make it into Debian.  I would like to get
> > this version into Debian if possible(as that is the distribution I
> > use), but that depends on Tobias' availability.
> 
> To have a chance to make that happen, I've started the transistion workflow 
> [1].
> TBH, due to the soft freeze is in less than two weeks, changes are high that
> we won't make it, but at least I want to have tried it.
> 
> The first step is "Upload your new version to experimental (and have it clear
> NEW)", which is what I've just have done: I've uploaded a snapshot (commit
> cbd23ff1) to debian experimental. This needs now to be approved by the 
> (Debian)
> ftp masters, which is (usually) for such a change quick, but if they aren't or
> not happy for any reason, this can spoil the game. [2]
> 
> Only after that, I can ask for a transition slot from the release team. If 
> they are
> not happy with a transition that late (IOW that short before the freeze), well
> that will be something I have to accept and that will mean 1.0.0 not in
> bookworm.
> 
> In parallel I'll see if the reverse dependencies are still building with the
> new version, as for any breakage I will need to have patches available…
> 
> So, let's see how it works out.
> 
> [1] if you want to know the details: 
> https://wiki.debian.org/Teams/ReleaseTeam/Transitions
> [2] It needs to go through NEW due to the binary package rename, due to the 
> SONAME bump.
> 
> -- 
> tobi


signature.asc
Description: PGP signature

Re: Log4j Maven plugin

[Matt Sicker]

Link to the self-service page: https://selfserve.apache.org/
—
Matt Sicker

> On Jan 2, 2023, at 09:31, Ralph Goers  wrote:
> 
> The groupId will almost always be “org.apache.logging.log4j” unless it isn’t 
> specifically for log4j. In that case the last token would be the 
> “category/subproject” it belongs to.
> 
> As far as where to put it you have a few choices. Any PMC member can create a 
> new repo so the only question is the name. All Logging Services repos must 
> start with “logging-“. So you could use “logging-maven-plugins” under the 
> assumption there may be multiple Maven plugins. More normal for plugins 
> though is for each to be in its own repo. So “logging-location-maven-plugin” 
> might be a decent repo name (although a bit long).
> 
> Ralph
> 
>> On Jan 1, 2023, at 1:59 PM, Piotr P. Karwasz  wrote:
>> 
>> Hi all,
>> 
>> After successfully merging my `LogBuilder` enhancement proposals, I
>> have a Maven plugin ready[#], which hardcodes location information in
>> a class's bytecode.
>> 
>> As Ralph remarks in the PR, the right place for this module is not
>> necessarily the `loggjing-log4j2` repository. I tend to agree with
>> this: the lifecycle of this plugin is not necessarily linked with
>> Log4j2. I have a long list of additional features I want to implement
>> in the near future (like migrating SLF4J, JCL and JUL bytecode to
>> Log4j2 API), but after that development will probably stop (apart from
>> some bug fixes).
>> 
>> Where do you think I should upload this code? What Maven groupId should I 
>> use?
>> 
>> Piotr
>> 
>> [#] https://github.com/apache/logging-log4j2/pull/1147
> 

Re: [apache/logging-log4j2] Run failed: build - master (8baedd7)

[Matt Sicker]

It’s a test that uses the real clock. Perhaps it has something to do with the 
new year?
—
Matt Sicker

> On Jan 2, 2023, at 11:25, Ralph Goers  wrote:
> 
> I don’t really understand why this failed. That test hasn’t been modified in 
> quite a while.
> 
> Ralph
> 
>> On Jan 2, 2023, at 9:20 AM, Ralph Goers  wrote:
>> 
>> 
>> 
>> [apache/logging-log4j2] build workflow run
>> 
>> 
>> 
>> build: Some jobs were not successful
>> 
>> View workflow run 
>> 
>> 
>> 
>> build / build (ubuntu-latest) 
>> Failed in 13 minutes and 56 seconds
>>  1 
>> 
>> build / build (windows-latest) 
>> Cancelled
>>  2 
>> 
>> build / build (macos-latest) 
>> Cancelled
>>  2 
>> 
>> build / deploy 
>> Skipped
>> 
>> 
>> 
>> —
>> You are receiving this because you are subscribed to this thread.
>> Manage your GitHub Actions notifications 
>> 
>> 
>> GitHub, Inc. ・88 Colin P Kelly Jr Street ・San Francisco, CA 94107
>> 
> 

Re: [apache/logging-log4j2] Run failed: build - master (8baedd7)

[Ralph Goers]

I don’t really understand why this failed. That test hasn’t been modified in 
quite a while.

Ralph

> On Jan 2, 2023, at 9:20 AM, Ralph Goers  wrote:
> 
>  
> 
> [apache/logging-log4j2] build workflow run
>  
> 
>  
> build: Some jobs were not successful
>  
> View workflow run 
> 
>  
>   
> build / build (ubuntu-latest) 
> Failed in 13 minutes and 56 seconds
>   1 
>   
> build / build (windows-latest) 
> Cancelled
>   2 
>   
> build / build (macos-latest) 
> Cancelled
>   2 
>   
> build / deploy 
> Skipped
>  
>  
> 
> —
> You are receiving this because you are subscribed to this thread.
> Manage your GitHub Actions notifications 
> 
>  
> GitHub, Inc. ・88 Colin P Kelly Jr Street ・San Francisco, CA 94107
> 

Re: Syncing `master`

[Ralph Goers]

That seems impractical as it will result in every commit creating a new issue 
since it isn’t possible to commit to both branches at once.

Ralph

> On Jan 2, 2023, at 1:50 AM, Volkan Yazıcı  wrote:
> 
> Suggestion: Shall we harness GitHub Actions to create a GitHub Issue
> telling commit X needs to be reflected on branch Y whenever a commit lands
> on branch Z?
> 
> If you all agree, I volunteer to set this up.
> 
> On Fri, Dec 30, 2022 at 9:48 AM Piotr P. Karwasz 
> wrote:
> 
>> Hi all,
>> 
>> As you know `master` is painfully lagging after `release-2.x`. The
>> main problem is that it is still diverging (in the wrong direction).
>> 
>> In the Tomcat repository you can observe 4 commits within minutes,
>> addressing the same issue in all 4 supported branches. Can we do
>> something similar in Log4j? What I mean is, whenever a commit occurs
>> on the `master` or `release-2.x` branches we:
>> 
>> * either receive 2 e-mails in a short timespan (5 minutes?), that
>> basically mean that we need to prepare 2 commits locally before
>> pushing it,
>> * receive 1 e-mail, but the commit message (not necessarily the title)
>> explains why the other branch has not been touched.
>> 
>> I have been trying to follow this for a couple of months and it is not
>> always easy: sometimes I can not push a commit/PR to `release-2.x`,
>> because `master` requires cherry-picking 5 other commits that we
>> forgot to cherry-pick before. And the commit is deferred by another
>> day...
>> 
>> "Next" weekend I'll try to write down the sync status of `master` on
>> the Wiki. I'll break it down into modules and for `log4j-core` into
>> packages.
>> 
>> Piotr
>> 

Re: Log4j Maven plugin

[Ralph Goers]

The groupId will almost always be “org.apache.logging.log4j” unless it isn’t 
specifically for log4j. In that case the last token would be the 
“category/subproject” it belongs to.

As far as where to put it you have a few choices. Any PMC member can create a 
new repo so the only question is the name. All Logging Services repos must 
start with “logging-“. So you could use “logging-maven-plugins” under the 
assumption there may be multiple Maven plugins. More normal for plugins though 
is for each to be in its own repo. So “logging-location-maven-plugin” might be 
a decent repo name (although a bit long).

Ralph

> On Jan 1, 2023, at 1:59 PM, Piotr P. Karwasz  wrote:
> 
> Hi all,
> 
> After successfully merging my `LogBuilder` enhancement proposals, I
> have a Maven plugin ready[#], which hardcodes location information in
> a class's bytecode.
> 
> As Ralph remarks in the PR, the right place for this module is not
> necessarily the `loggjing-log4j2` repository. I tend to agree with
> this: the lifecycle of this plugin is not necessarily linked with
> Log4j2. I have a long list of additional features I want to implement
> in the near future (like migrating SLF4J, JCL and JUL bytecode to
> Log4j2 API), but after that development will probably stop (apart from
> some bug fixes).
> 
> Where do you think I should upload this code? What Maven groupId should I use?
> 
> Piotr
> 
> [#] https://github.com/apache/logging-log4j2/pull/1147

Re: Log4j Maven plugin

[Volkan Yazıcı]

Great job, Piotr! 

Agreed with the separate repository idea. I suggest moving it to the
`logging-log4j-maven-plugins` repository – you need an INFRA ticket to
create the repository.

If we go that route, I strongly suggest incorporating following goodies
from the `logging-log4j-tools` repository:

   - GitHub Actions `build.yml` (the repository path there needs to be
   adapted)
   - `/pom.xml` + `log4j-tools-parent/pom.xml` (Note that you need neither
   a `-bom`, nor a `-parent` module! Adding sources to the root module should
   suffice.)
   - `CHANGELOG.adoc`
   - `LICENSE.txt`
   - `SECURITY.adoc`
   - `spotless-license-header.txt`
   - `.editorconfig`
   - `.asf.yaml` (`github.description` needs to be updated here)
   - `.gitignore`
   - `.java-version`

 I put a great deal of effort into their correctness and compactness, hence
my insistence on reusing them.

On Sun, Jan 1, 2023 at 10:00 PM Piotr P. Karwasz 
wrote:

> Hi all,
>
> After successfully merging my `LogBuilder` enhancement proposals, I
> have a Maven plugin ready[#], which hardcodes location information in
> a class's bytecode.
>
> As Ralph remarks in the PR, the right place for this module is not
> necessarily the `loggjing-log4j2` repository. I tend to agree with
> this: the lifecycle of this plugin is not necessarily linked with
> Log4j2. I have a long list of additional features I want to implement
> in the near future (like migrating SLF4J, JCL and JUL bytecode to
> Log4j2 API), but after that development will probably stop (apart from
> some bug fixes).
>
> Where do you think I should upload this code? What Maven groupId should I
> use?
>
> Piotr
>
> [#] https://github.com/apache/logging-log4j2/pull/1147
>

Re: Syncing `master`

[Volkan Yazıcı]

Suggestion: Shall we harness GitHub Actions to create a GitHub Issue
telling commit X needs to be reflected on branch Y whenever a commit lands
on branch Z?

If you all agree, I volunteer to set this up.

On Fri, Dec 30, 2022 at 9:48 AM Piotr P. Karwasz 
wrote:

> Hi all,
>
> As you know `master` is painfully lagging after `release-2.x`. The
> main problem is that it is still diverging (in the wrong direction).
>
> In the Tomcat repository you can observe 4 commits within minutes,
> addressing the same issue in all 4 supported branches. Can we do
> something similar in Log4j? What I mean is, whenever a commit occurs
> on the `master` or `release-2.x` branches we:
>
> * either receive 2 e-mails in a short timespan (5 minutes?), that
> basically mean that we need to prepare 2 commits locally before
> pushing it,
> * receive 1 e-mail, but the commit message (not necessarily the title)
> explains why the other branch has not been touched.
>
> I have been trying to follow this for a couple of months and it is not
> always easy: sometimes I can not push a commit/PR to `release-2.x`,
> because `master` requires cherry-picking 5 other commits that we
> forgot to cherry-pick before. And the commit is deferred by another
> day...
>
> "Next" weekend I'll try to write down the sync status of `master` on
> the Wiki. I'll break it down into modules and for `log4j-core` into
> packages.
>
> Piotr
>