You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@logging.apache.org by "Piotr P. Karwasz" <pi...@gmail.com> on 2023/05/02 19:08:40 UTC
[VOTE] (RC3) Release Apache Log4j Transformation Tools 0.1.0
The Apache Log4j Transformation Tools 0.1.0 release is now available for voting.
This is the first release and it contains two modules:
* [LOG4J2-3638]: Adds a bytecode transformation tool to provide
location information without reflection.
* [LOG4J2-673]: Adds a resource transformer for the Maven Shade Plugin
to merge `Log4j2Plugins.dat` plugin caches. Thanks to Eduard
Gizatullin.
Changes between RC2 and RC3:
* The `log4j-transform-maven-plugin` has a `includes/excludes` setting
now (useful for benchmark testing),
* There is a `log4j-transform-perf` module (not in the main reactor
for a chicken and egg problem),
* The release was fully automated (hence the 0.1.0-rc1 tag instead of
0.1.0-rc3 tag due to some differences between my bash and Github),
* The source archive does not have Git and Github-related stuff (thanks Gary).
Source repository: https://github.com/apache/logging-log4j-transform
Tag: rel/0.1.0-rc1
Commit: b49a898f74e1ceaa8cd883f211c0a9c30ef8f5c1
Artifacts: https://dist.apache.org/repos/dist/dev/logging/log4j-transform/0.1.0
Nexus repository:
https://repository.apache.org/content/repositories/orgapachelogging-1106
CI job run: https://github.com/apache/logging-log4j-transform/actions/runs/4864531191
Signing key: https://keyserver.ubuntu.com/pks/lookup?search=077e8893a6dcc33dd4a4d5b256e73ba9a0b592d0&fingerprint=on&op=index
Website: https://logging.staged.apache.org/log4j/2.x/log4j-transform
Please download, test, and cast your votes on the Log4j developers list.
[ ] +1, release the artifacts
[ ] -1, don't release, because...
The vote will remain open for 72 hours 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.
Countdown: https://www.timeanddate.com/countdown/launch?iso=20230505T2115&p0=4162&msg=Log4j+Transformation+Tools+0.1.0&font=cursive
Re: `rel`-prefixed tags (Was: [VOTE] (RC3) Release Apache Log4j Transformation Tools 0.1.0)
Posted by Ralph Goers <ra...@dslextreme.com>.
Yes, the maven release plugin creates tags (unless you configure it to create a branch instead). But Volkan is not using the release plugin.
I am not really sure what the issue is with creating a tag named log4j-tools-1.1.0-rc1. These tags can be deleted later if you don’t want them once the rel tag is created.
Yes, one can work from the commit id but that is a bit cumbersome.
Ralph
> On May 5, 2023, at 9:11 AM, Matt Sicker <ma...@musigma.org> wrote:
>
> This sounds reasonable, though I wonder how it works with the maven-release-plugin? I thought that automatically created tags.
>
>> On May 5, 2023, at 3:47 AM, Volkan Yazıcı <vo...@yazi.ci> wrote:
>>
>> INFRA has dropped the `rel`-prefixed tag requirement. (See this
>> `users@infra` thread
>> <https://lists.apache.org/thread/snkhvbc6vzz58h4r595jy6gbb9hy8rfl>.)
>>
>> Yet I get the team's sentiment on provenance and I agree with it. Yet the
>> RC (release candidates) case is a bit muddy. I propose the following: For
>> voting purposes, only share the commit ID, and only create a `rel/x.y.z`
>> tag if the vote passes.
>>
>> This captures two conditions stated so far:
>> 1. Not polluting the tag-space
>> 2. Immutable references to release commits
>>
>> Unless you have objections, I will implement this for `l-l-tools` and
>> `l-l-transform`.
>>
>> ---------- Forwarded message ---------
>> From: Ralph Goers <ra...@dslextreme.com>
>> Date: Fri, May 5, 2023 at 6:17 AM
>> Subject: Re: [VOTE] (RC3) Release Apache Log4j Transformation Tools 0.1.0
>> To: <de...@logging.apache.org>
>>
>>
>> OK, thanks for the clarification. I do have a strong opinion. Infra made it
>> clear that rel/ is for tagging releases. Release candidates are NOT
>> releases. Furthermore, if you find a problem before starting a vote it is
>> very easy to just delete a non-rel/ tag and rerun the candidate. Once the
>> vote starts the tag should not be deleted but it is otherwise very
>> confusing to have a vote on rel/1.0-rc1 followed by a vote on rel/1.0-rc3
>> or rc4. What happened to the missing candidates? It just creates needless
>> permanent tags in the repo and gets annoying for users who are looking for
>> just the “real” release tags.
>>
>> Release candidates should ALWAYS use a tag that is completely separate from
>> the release tags for the above reasons. To be honest, I might consider
>> voting -1 on future releases that don’t do that.
>>
>> Ralph
>>
>>> On May 4, 2023, at 1:48 PM, Piotr P. Karwasz <pi...@gmail.com>
>> wrote:
>>>
>>> Hi Ralph,
>>>
>>> On Thu, 4 May 2023 at 22:35, Ralph Goers <ra...@dslextreme.com>
>> wrote:
>>>>
>>>> That makes me question what is in the actual release. Tags named “rel/“
>> are immutable so you can’t have added anything to that after the first rc.
>>>
>>> It took me a while to get the automatic release scripts going. So there
>> was:
>>>
>>> * rel/0.1.0.rc1 (with a dot): first attempt with
>>> `maven-release-plugin`, which pushed the tag,
>>> * rel/0.1.0-rc2: second release candidate, first deployed by Github
>>> Actions, the tag is mine,
>>> * rel/0.1.0-rc1 (as in the vote e-mail): third release candidate,
>>> deployed by Github Actions, the tag was also pushed by GA. In an
>>> effort to order things up I manually pushed `rel/0.1.0-rc3`.
>>>
>>> Sorry for the confusion. I guess the tagging policy will be a hot
>>> topic of the next meeting. Personally I don't have a strong opinion in
>>> this regard, I just copied what `l-l-tools` does.
>>>
>>> Piotr
>
Re: `rel`-prefixed tags (Was: [VOTE] (RC3) Release Apache Log4j Transformation Tools 0.1.0)
Posted by Matt Sicker <ma...@musigma.org>.
This sounds reasonable, though I wonder how it works with the maven-release-plugin? I thought that automatically created tags.
> On May 5, 2023, at 3:47 AM, Volkan Yazıcı <vo...@yazi.ci> wrote:
>
> INFRA has dropped the `rel`-prefixed tag requirement. (See this
> `users@infra` thread
> <https://lists.apache.org/thread/snkhvbc6vzz58h4r595jy6gbb9hy8rfl>.)
>
> Yet I get the team's sentiment on provenance and I agree with it. Yet the
> RC (release candidates) case is a bit muddy. I propose the following: For
> voting purposes, only share the commit ID, and only create a `rel/x.y.z`
> tag if the vote passes.
>
> This captures two conditions stated so far:
> 1. Not polluting the tag-space
> 2. Immutable references to release commits
>
> Unless you have objections, I will implement this for `l-l-tools` and
> `l-l-transform`.
>
> ---------- Forwarded message ---------
> From: Ralph Goers <ra...@dslextreme.com>
> Date: Fri, May 5, 2023 at 6:17 AM
> Subject: Re: [VOTE] (RC3) Release Apache Log4j Transformation Tools 0.1.0
> To: <de...@logging.apache.org>
>
>
> OK, thanks for the clarification. I do have a strong opinion. Infra made it
> clear that rel/ is for tagging releases. Release candidates are NOT
> releases. Furthermore, if you find a problem before starting a vote it is
> very easy to just delete a non-rel/ tag and rerun the candidate. Once the
> vote starts the tag should not be deleted but it is otherwise very
> confusing to have a vote on rel/1.0-rc1 followed by a vote on rel/1.0-rc3
> or rc4. What happened to the missing candidates? It just creates needless
> permanent tags in the repo and gets annoying for users who are looking for
> just the “real” release tags.
>
> Release candidates should ALWAYS use a tag that is completely separate from
> the release tags for the above reasons. To be honest, I might consider
> voting -1 on future releases that don’t do that.
>
> Ralph
>
>> On May 4, 2023, at 1:48 PM, Piotr P. Karwasz <pi...@gmail.com>
> wrote:
>>
>> Hi Ralph,
>>
>> On Thu, 4 May 2023 at 22:35, Ralph Goers <ra...@dslextreme.com>
> wrote:
>>>
>>> That makes me question what is in the actual release. Tags named “rel/“
> are immutable so you can’t have added anything to that after the first rc.
>>
>> It took me a while to get the automatic release scripts going. So there
> was:
>>
>> * rel/0.1.0.rc1 (with a dot): first attempt with
>> `maven-release-plugin`, which pushed the tag,
>> * rel/0.1.0-rc2: second release candidate, first deployed by Github
>> Actions, the tag is mine,
>> * rel/0.1.0-rc1 (as in the vote e-mail): third release candidate,
>> deployed by Github Actions, the tag was also pushed by GA. In an
>> effort to order things up I manually pushed `rel/0.1.0-rc3`.
>>
>> Sorry for the confusion. I guess the tagging policy will be a hot
>> topic of the next meeting. Personally I don't have a strong opinion in
>> this regard, I just copied what `l-l-tools` does.
>>
>> Piotr
Re: `rel`-prefixed tags
Posted by "Piotr P. Karwasz" <pi...@gmail.com>.
Hi Volkan,
On Mon, 15 May 2023 at 12:47, Volkan Yazıcı <vo...@yazi.ci> wrote:
> > release deployment should **not** be triggered by a push. I should
> > be a `workflow_dispatch` triggered manually with parameters (e.g. the
> > release number). I almost triggered RC4 when merging `release/0.1.0`
> > with `main`,
>
> Assuming that, as agreed, RC tags won't be generated by CI anymore, do you
> still think this is a problem? Note that the entire release process
> performed by CI is reversible. I personally really like the convenience of
> "push a commit and see it getting released" compared to "push a commit,
> trigger the job, and see it getting released". In particular, given "push a
> commit" is often repeated many times.
What about triggering the release process when you push a tag with a
specific format (e.g. `log4j-transform-0.1.1-rc1`) regardless of the
branch?
When I merge a PR I need to sign it. So I usually rebase the PR branch
on top of main and push both branches. This way Github automatically
closes the PR.
That is why I would rather use something else for the release process
to prevent errors due to muscle memory.
> > we could reuse some Github Actions like
> > https://github.com/apache/maven-gh-actions-shared/tree/v3
>
> I did not know about that project, thanks for the tip. I have some
> reservations about using an Apache-wide GHA template, but I support the
> idea of moving the shared boilerplate to a central (Log4j?) repository.
+1 for a `logging-log4j-actions` repo
> > the CI build should use all bells and whistles. E.g. I will disable
> > integration tests in the default build profile on `l-l-transform`,
> > because it slows down builds considerably. But I want the CI to run
> > them.
>
> I suppose you need to create a Maven profile that gets deactivated when the
> `CI` environment variable
> <https://docs.github.com/en/actions/learn-github-actions/variables#default-environment-variables>
> is present and bind your tests to that profile.
+1, I'll implement it in `l-l-transform`.
> > a `verify-release` profile would be useful. There is no reason to
> > verify build reproducibility manually. An `artifact:compare` execution
> > should be able to do it.
>
> I am not able to follow here. Build reproducibility is tested in multiple
> steps:
What I meant is: it would be nice to have a `verify-release` profile
so that PMC members can verify that their locally generated artifacts
are identical with those in the Nexus staging repo.
When a release vote comes out you just run something like:
./mvnw clean verify -Pverify-release -DstagingRepo=1234
Piotr
Re: `rel`-prefixed tags (Was: [VOTE] (RC3) Release Apache Log4j Transformation Tools 0.1.0)
Posted by Volkan Yazıcı <vo...@yazi.ci>.
Hey Piotr,
> release deployment should **not** be triggered by a push. I should
> be a `workflow_dispatch` triggered manually with parameters (e.g. the
> release number). I almost triggered RC4 when merging `release/0.1.0`
> with `main`,
Assuming that, as agreed, RC tags won't be generated by CI anymore, do you
still think this is a problem? Note that the entire release process
performed by CI is reversible. I personally really like the convenience of
"push a commit and see it getting released" compared to "push a commit,
trigger the job, and see it getting released". In particular, given "push a
commit" is often repeated many times.
> we could reuse some Github Actions like
> https://github.com/apache/maven-gh-actions-shared/tree/v3
I did not know about that project, thanks for the tip. I have some
reservations about using an Apache-wide GHA template, but I support the
idea of moving the shared boilerplate to a central (Log4j?) repository.
> the CI build should use all bells and whistles. E.g. I will disable
> integration tests in the default build profile on `l-l-transform`,
> because it slows down builds considerably. But I want the CI to run
> them.
I suppose you need to create a Maven profile that gets deactivated when the
`CI` environment variable
<https://docs.github.com/en/actions/learn-github-actions/variables#default-environment-variables>
is present and bind your tests to that profile.
> a `verify-release` profile would be useful. There is no reason to
> verify build reproducibility manually. An `artifact:compare` execution
> should be able to do it.
I am not able to follow here. Build reproducibility is tested in multiple
steps:
1. `./mvnw clean install`
2. `./mvnw clean verify artifact:compare`
3. Store the failure context (optional)
How can we attach this sequence to a single (Maven?) profile?
On Fri, May 5, 2023 at 11:13 PM Piotr P. Karwasz <pi...@gmail.com>
wrote:
> Hi Volkan,
>
> On Fri, 5 May 2023 at 10:47, Volkan Yazıcı <vo...@yazi.ci> wrote:
> > Yet I get the team's sentiment on provenance and I agree with it. Yet the
> > RC (release candidates) case is a bit muddy. I propose the following: For
> > voting purposes, only share the commit ID, and only create a `rel/x.y.z`
> > tag if the vote passes.
> >
> > This captures two conditions stated so far:
> > 1. Not polluting the tag-space
> > 2. Immutable references to release commits
> >
> > Unless you have objections, I will implement this for `l-l-tools` and
> > `l-l-transform`.
>
> +1
>
> Some remarks on my experience with the automatic release process:
>
> * release deployment should **not** be triggered by a push. I should
> be a `workflow_dispatch` triggered manually with parameters (e.g. the
> release number). I almost triggered RC4 when merging `release/0.1.0`
> with `main`,
> * we could reuse some Github Actions like
> https://github.com/apache/maven-gh-actions-shared/tree/v3
> * the CI build should use all bells and whistles. E.g. I will disable
> integration tests in the default build profile on `l-l-transform`,
> because it slows down builds considerably. But I want the CI to run
> them.
> * a `verify-release` profile would be useful. There is no reason to
> verify build reproducibility manually. An `artifact:compare` execution
> should be able to do it.
>
> Piotr
>
Re: `rel`-prefixed tags (Was: [VOTE] (RC3) Release Apache Log4j Transformation Tools 0.1.0)
Posted by "Piotr P. Karwasz" <pi...@gmail.com>.
Hi Volkan,
On Fri, 5 May 2023 at 10:47, Volkan Yazıcı <vo...@yazi.ci> wrote:
> Yet I get the team's sentiment on provenance and I agree with it. Yet the
> RC (release candidates) case is a bit muddy. I propose the following: For
> voting purposes, only share the commit ID, and only create a `rel/x.y.z`
> tag if the vote passes.
>
> This captures two conditions stated so far:
> 1. Not polluting the tag-space
> 2. Immutable references to release commits
>
> Unless you have objections, I will implement this for `l-l-tools` and
> `l-l-transform`.
+1
Some remarks on my experience with the automatic release process:
* release deployment should **not** be triggered by a push. I should
be a `workflow_dispatch` triggered manually with parameters (e.g. the
release number). I almost triggered RC4 when merging `release/0.1.0`
with `main`,
* we could reuse some Github Actions like
https://github.com/apache/maven-gh-actions-shared/tree/v3
* the CI build should use all bells and whistles. E.g. I will disable
integration tests in the default build profile on `l-l-transform`,
because it slows down builds considerably. But I want the CI to run
them.
* a `verify-release` profile would be useful. There is no reason to
verify build reproducibility manually. An `artifact:compare` execution
should be able to do it.
Piotr
`rel`-prefixed tags (Was: [VOTE] (RC3) Release Apache Log4j Transformation Tools 0.1.0)
Posted by Volkan Yazıcı <vo...@yazi.ci>.
INFRA has dropped the `rel`-prefixed tag requirement. (See this
`users@infra` thread
<https://lists.apache.org/thread/snkhvbc6vzz58h4r595jy6gbb9hy8rfl>.)
Yet I get the team's sentiment on provenance and I agree with it. Yet the
RC (release candidates) case is a bit muddy. I propose the following: For
voting purposes, only share the commit ID, and only create a `rel/x.y.z`
tag if the vote passes.
This captures two conditions stated so far:
1. Not polluting the tag-space
2. Immutable references to release commits
Unless you have objections, I will implement this for `l-l-tools` and
`l-l-transform`.
---------- Forwarded message ---------
From: Ralph Goers <ra...@dslextreme.com>
Date: Fri, May 5, 2023 at 6:17 AM
Subject: Re: [VOTE] (RC3) Release Apache Log4j Transformation Tools 0.1.0
To: <de...@logging.apache.org>
OK, thanks for the clarification. I do have a strong opinion. Infra made it
clear that rel/ is for tagging releases. Release candidates are NOT
releases. Furthermore, if you find a problem before starting a vote it is
very easy to just delete a non-rel/ tag and rerun the candidate. Once the
vote starts the tag should not be deleted but it is otherwise very
confusing to have a vote on rel/1.0-rc1 followed by a vote on rel/1.0-rc3
or rc4. What happened to the missing candidates? It just creates needless
permanent tags in the repo and gets annoying for users who are looking for
just the “real” release tags.
Release candidates should ALWAYS use a tag that is completely separate from
the release tags for the above reasons. To be honest, I might consider
voting -1 on future releases that don’t do that.
Ralph
> On May 4, 2023, at 1:48 PM, Piotr P. Karwasz <pi...@gmail.com>
wrote:
>
> Hi Ralph,
>
> On Thu, 4 May 2023 at 22:35, Ralph Goers <ra...@dslextreme.com>
wrote:
>>
>> That makes me question what is in the actual release. Tags named “rel/“
are immutable so you can’t have added anything to that after the first rc.
>
> It took me a while to get the automatic release scripts going. So there
was:
>
> * rel/0.1.0.rc1 (with a dot): first attempt with
> `maven-release-plugin`, which pushed the tag,
> * rel/0.1.0-rc2: second release candidate, first deployed by Github
> Actions, the tag is mine,
> * rel/0.1.0-rc1 (as in the vote e-mail): third release candidate,
> deployed by Github Actions, the tag was also pushed by GA. In an
> effort to order things up I manually pushed `rel/0.1.0-rc3`.
>
> Sorry for the confusion. I guess the tagging policy will be a hot
> topic of the next meeting. Personally I don't have a strong opinion in
> this regard, I just copied what `l-l-tools` does.
>
> Piotr
Re: [VOTE] (RC3) Release Apache Log4j Transformation Tools 0.1.0
Posted by Ralph Goers <ra...@dslextreme.com>.
OK, thanks for the clarification. I do have a strong opinion. Infra made it clear that rel/ is for tagging releases. Release candidates are NOT releases. Furthermore, if you find a problem before starting a vote it is very easy to just delete a non-rel/ tag and rerun the candidate. Once the vote starts the tag should not be deleted but it is otherwise very confusing to have a vote on rel/1.0-rc1 followed by a vote on rel/1.0-rc3 or rc4. What happened to the missing candidates? It just creates needless permanent tags in the repo and gets annoying for users who are looking for just the “real” release tags.
Release candidates should ALWAYS use a tag that is completely separate from the release tags for the above reasons. To be honest, I might consider voting -1 on future releases that don’t do that.
Ralph
> On May 4, 2023, at 1:48 PM, Piotr P. Karwasz <pi...@gmail.com> wrote:
>
> Hi Ralph,
>
> On Thu, 4 May 2023 at 22:35, Ralph Goers <ra...@dslextreme.com> wrote:
>>
>> That makes me question what is in the actual release. Tags named “rel/“ are immutable so you can’t have added anything to that after the first rc.
>
> It took me a while to get the automatic release scripts going. So there was:
>
> * rel/0.1.0.rc1 (with a dot): first attempt with
> `maven-release-plugin`, which pushed the tag,
> * rel/0.1.0-rc2: second release candidate, first deployed by Github
> Actions, the tag is mine,
> * rel/0.1.0-rc1 (as in the vote e-mail): third release candidate,
> deployed by Github Actions, the tag was also pushed by GA. In an
> effort to order things up I manually pushed `rel/0.1.0-rc3`.
>
> Sorry for the confusion. I guess the tagging policy will be a hot
> topic of the next meeting. Personally I don't have a strong opinion in
> this regard, I just copied what `l-l-tools` does.
>
> Piotr
Re: [VOTE] (RC3) Release Apache Log4j Transformation Tools 0.1.0
Posted by "Piotr P. Karwasz" <pi...@gmail.com>.
Hi Ralph,
On Thu, 4 May 2023 at 22:35, Ralph Goers <ra...@dslextreme.com> wrote:
>
> That makes me question what is in the actual release. Tags named “rel/“ are immutable so you can’t have added anything to that after the first rc.
It took me a while to get the automatic release scripts going. So there was:
* rel/0.1.0.rc1 (with a dot): first attempt with
`maven-release-plugin`, which pushed the tag,
* rel/0.1.0-rc2: second release candidate, first deployed by Github
Actions, the tag is mine,
* rel/0.1.0-rc1 (as in the vote e-mail): third release candidate,
deployed by Github Actions, the tag was also pushed by GA. In an
effort to order things up I manually pushed `rel/0.1.0-rc3`.
Sorry for the confusion. I guess the tagging policy will be a hot
topic of the next meeting. Personally I don't have a strong opinion in
this regard, I just copied what `l-l-tools` does.
Piotr
Re: [VOTE] (RC3) Release Apache Log4j Transformation Tools 0.1.0
Posted by Ralph Goers <ra...@dslextreme.com>.
That makes me question what is in the actual release. Tags named “rel/“ are immutable so you can’t have added anything to that after the first rc.
Ralph
> On May 4, 2023, at 1:31 PM, Piotr P. Karwasz <pi...@gmail.com> wrote:
>
> Hi Matt,
>
> On Thu, 4 May 2023 at 22:09, Matt Sicker <ma...@musigma.org> wrote:
>>
>> Which tag is it? I see ‘rel/0.1.0-rc1’ and then references to RC2 and RC3?
>
> It's `rel/0.1.0-rc1` due to a bug in the CI scripts. I added
> `rel/0.1.0-rc3` right now to partially correct it.
>
> Piotr
Re: [VOTE] (RC3) Release Apache Log4j Transformation Tools 0.1.0
Posted by "Piotr P. Karwasz" <pi...@gmail.com>.
Hi Matt,
On Thu, 4 May 2023 at 22:09, Matt Sicker <ma...@musigma.org> wrote:
>
> Which tag is it? I see ‘rel/0.1.0-rc1’ and then references to RC2 and RC3?
It's `rel/0.1.0-rc1` due to a bug in the CI scripts. I added
`rel/0.1.0-rc3` right now to partially correct it.
Piotr
Re: [VOTE] (RC3) Release Apache Log4j Transformation Tools 0.1.0
Posted by Ralph Goers <ra...@dslextreme.com>.
The vote email says Tag: rel/0.1.0-rc1. That can’t be correct.
Ralph
> On May 4, 2023, at 1:10 PM, Matt Sicker <ma...@musigma.org> wrote:
>
> And no tag containing the term “rc3” in git, either.
>
>> On May 4, 2023, at 3:09 PM, Matt Sicker <ma...@musigma.org> wrote:
>>
>> Which tag is it? I see ‘rel/0.1.0-rc1’ and then references to RC2 and RC3?
>>
>>> On May 2, 2023, at 2:08 PM, Piotr P. Karwasz <pi...@gmail.com> wrote:
>>>
>>> The Apache Log4j Transformation Tools 0.1.0 release is now available for voting.
>>>
>>> This is the first release and it contains two modules:
>>>
>>> * [LOG4J2-3638]: Adds a bytecode transformation tool to provide
>>> location information without reflection.
>>> * [LOG4J2-673]: Adds a resource transformer for the Maven Shade Plugin
>>> to merge `Log4j2Plugins.dat` plugin caches. Thanks to Eduard
>>> Gizatullin.
>>>
>>> Changes between RC2 and RC3:
>>>
>>> * The `log4j-transform-maven-plugin` has a `includes/excludes` setting
>>> now (useful for benchmark testing),
>>> * There is a `log4j-transform-perf` module (not in the main reactor
>>> for a chicken and egg problem),
>>> * The release was fully automated (hence the 0.1.0-rc1 tag instead of
>>> 0.1.0-rc3 tag due to some differences between my bash and Github),
>>> * The source archive does not have Git and Github-related stuff (thanks Gary).
>>>
>>> Source repository: https://github.com/apache/logging-log4j-transform
>>> Tag: rel/0.1.0-rc1
>>> Commit: b49a898f74e1ceaa8cd883f211c0a9c30ef8f5c1
>>> Artifacts: https://dist.apache.org/repos/dist/dev/logging/log4j-transform/0.1.0
>>> Nexus repository:
>>> https://repository.apache.org/content/repositories/orgapachelogging-1106
>>> CI job run: https://github.com/apache/logging-log4j-transform/actions/runs/4864531191
>>> Signing key: https://keyserver.ubuntu.com/pks/lookup?search=077e8893a6dcc33dd4a4d5b256e73ba9a0b592d0&fingerprint=on&op=index
>>> Website: https://logging.staged.apache.org/log4j/2.x/log4j-transform
>>>
>>> Please download, test, and cast your votes on the Log4j developers list.
>>>
>>> [ ] +1, release the artifacts
>>> [ ] -1, don't release, because...
>>>
>>> The vote will remain open for 72 hours 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.
>>>
>>> Countdown: https://www.timeanddate.com/countdown/launch?iso=20230505T2115&p0=4162&msg=Log4j+Transformation+Tools+0.1.0&font=cursive
>>
>
Re: [VOTE] (RC3) Release Apache Log4j Transformation Tools 0.1.0
Posted by Matt Sicker <ma...@musigma.org>.
And no tag containing the term “rc3” in git, either.
> On May 4, 2023, at 3:09 PM, Matt Sicker <ma...@musigma.org> wrote:
>
> Which tag is it? I see ‘rel/0.1.0-rc1’ and then references to RC2 and RC3?
>
>> On May 2, 2023, at 2:08 PM, Piotr P. Karwasz <pi...@gmail.com> wrote:
>>
>> The Apache Log4j Transformation Tools 0.1.0 release is now available for voting.
>>
>> This is the first release and it contains two modules:
>>
>> * [LOG4J2-3638]: Adds a bytecode transformation tool to provide
>> location information without reflection.
>> * [LOG4J2-673]: Adds a resource transformer for the Maven Shade Plugin
>> to merge `Log4j2Plugins.dat` plugin caches. Thanks to Eduard
>> Gizatullin.
>>
>> Changes between RC2 and RC3:
>>
>> * The `log4j-transform-maven-plugin` has a `includes/excludes` setting
>> now (useful for benchmark testing),
>> * There is a `log4j-transform-perf` module (not in the main reactor
>> for a chicken and egg problem),
>> * The release was fully automated (hence the 0.1.0-rc1 tag instead of
>> 0.1.0-rc3 tag due to some differences between my bash and Github),
>> * The source archive does not have Git and Github-related stuff (thanks Gary).
>>
>> Source repository: https://github.com/apache/logging-log4j-transform
>> Tag: rel/0.1.0-rc1
>> Commit: b49a898f74e1ceaa8cd883f211c0a9c30ef8f5c1
>> Artifacts: https://dist.apache.org/repos/dist/dev/logging/log4j-transform/0.1.0
>> Nexus repository:
>> https://repository.apache.org/content/repositories/orgapachelogging-1106
>> CI job run: https://github.com/apache/logging-log4j-transform/actions/runs/4864531191
>> Signing key: https://keyserver.ubuntu.com/pks/lookup?search=077e8893a6dcc33dd4a4d5b256e73ba9a0b592d0&fingerprint=on&op=index
>> Website: https://logging.staged.apache.org/log4j/2.x/log4j-transform
>>
>> Please download, test, and cast your votes on the Log4j developers list.
>>
>> [ ] +1, release the artifacts
>> [ ] -1, don't release, because...
>>
>> The vote will remain open for 72 hours 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.
>>
>> Countdown: https://www.timeanddate.com/countdown/launch?iso=20230505T2115&p0=4162&msg=Log4j+Transformation+Tools+0.1.0&font=cursive
>
Re: [VOTE] (RC3) Release Apache Log4j Transformation Tools 0.1.0
Posted by Matt Sicker <ma...@musigma.org>.
Which tag is it? I see ‘rel/0.1.0-rc1’ and then references to RC2 and RC3?
> On May 2, 2023, at 2:08 PM, Piotr P. Karwasz <pi...@gmail.com> wrote:
>
> The Apache Log4j Transformation Tools 0.1.0 release is now available for voting.
>
> This is the first release and it contains two modules:
>
> * [LOG4J2-3638]: Adds a bytecode transformation tool to provide
> location information without reflection.
> * [LOG4J2-673]: Adds a resource transformer for the Maven Shade Plugin
> to merge `Log4j2Plugins.dat` plugin caches. Thanks to Eduard
> Gizatullin.
>
> Changes between RC2 and RC3:
>
> * The `log4j-transform-maven-plugin` has a `includes/excludes` setting
> now (useful for benchmark testing),
> * There is a `log4j-transform-perf` module (not in the main reactor
> for a chicken and egg problem),
> * The release was fully automated (hence the 0.1.0-rc1 tag instead of
> 0.1.0-rc3 tag due to some differences between my bash and Github),
> * The source archive does not have Git and Github-related stuff (thanks Gary).
>
> Source repository: https://github.com/apache/logging-log4j-transform
> Tag: rel/0.1.0-rc1
> Commit: b49a898f74e1ceaa8cd883f211c0a9c30ef8f5c1
> Artifacts: https://dist.apache.org/repos/dist/dev/logging/log4j-transform/0.1.0
> Nexus repository:
> https://repository.apache.org/content/repositories/orgapachelogging-1106
> CI job run: https://github.com/apache/logging-log4j-transform/actions/runs/4864531191
> Signing key: https://keyserver.ubuntu.com/pks/lookup?search=077e8893a6dcc33dd4a4d5b256e73ba9a0b592d0&fingerprint=on&op=index
> Website: https://logging.staged.apache.org/log4j/2.x/log4j-transform
>
> Please download, test, and cast your votes on the Log4j developers list.
>
> [ ] +1, release the artifacts
> [ ] -1, don't release, because...
>
> The vote will remain open for 72 hours 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.
>
> Countdown: https://www.timeanddate.com/countdown/launch?iso=20230505T2115&p0=4162&msg=Log4j+Transformation+Tools+0.1.0&font=cursive
Re: [VOTE] (RC3) Release Apache Log4j Transformation Tools 0.1.0
Posted by "Piotr P. Karwasz" <pi...@gmail.com>.
On Fri, 5 May 2023 at 18:09, Ralph Goers <ra...@dslextreme.com> wrote:
>
> +1
> (With minor reservations)
And this is my +1 (also with minor reservations).
All Maven artifacts are reproducible,
The source archive has been also attached to `log4j-transform-bom`. It
can have reproducibility problems if computed on a non-entirely clean
git repo: empty directories are not detected as changes by git, but
end up in the source archive.
Anyway: the RC3 vote passes with binding votes from Ralph, Volkan and myself.
I'll continue the release process.
Piotr
Re: [VOTE] (RC3) Release Apache Log4j Transformation Tools 0.1.0
Posted by Ralph Goers <ra...@dslextreme.com>.
+1
(With minor reservations)
It built (but took 15 minutes)
The artifact is properly signed.
Verifying the hash still doesn’t work properly
shasum -a 512 --check apache-log4j-transform-0.1.0-src.zip.sha512
shasum: apache-log4j-transform-0.1.0-src.zip.sha512: no properly formatted SHA checksum lines found
This is because the sha512 file only contains the hash and no longer has the file name. I suggest looking at the log4j 2.x distribution pom.
I built and ran my test project and it ran fine. However, the first time I ran my project build it failed as below. I ran it several more times and it worked the second time, failed the same way the third time and then worked the few times I ran it again after that.
[ERROR] Failed to execute goal org.apache.logging.log4j:log4j-transform-maven-plugin:0.1.0:process-classes (default) on project customer-engagement-service: Execution default of goal org.apache.logging.log4j:log4j-transform-maven-plugin:0.1.0:process-classes failed: An API incompatibility was encountered while executing org.apache.logging.log4j:log4j-transform-maven-plugin:0.1.0:process-classes: java.lang.ClassFormatError: Truncated class file
[ERROR] -----------------------------------------------------
[ERROR] realm = plugin>org.apache.logging.log4j:log4j-transform-maven-plugin:0.1.0
[ERROR] strategy = org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy
[ERROR] urls[0] = file:/Users/rgoers/.m2/repository/org/apache/logging/log4j/log4j-transform-maven-plugin/0.1.0/log4j-transform-maven-plugin-0.1.0.jar
[ERROR] urls[1] = file:/Users/rgoers/.m2/repository/org/apache/logging/log4j/log4j-weaver/0.1.0/log4j-weaver-0.1.0.jar
[ERROR] urls[2] = file:/Users/rgoers/.m2/repository/org/ow2/asm/asm/9.5/asm-9.5.jar
[ERROR] urls[3] = file:/Users/rgoers/.m2/repository/org/ow2/asm/asm-commons/9.5/asm-commons-9.5.jar
[ERROR] urls[4] = file:/Users/rgoers/.m2/repository/org/ow2/asm/asm-tree/9.5/asm-tree-9.5.jar
[ERROR] urls[5] = file:/Users/rgoers/.m2/repository/org/ow2/asm/asm-util/9.5/asm-util-9.5.jar
[ERROR] urls[6] = file:/Users/rgoers/.m2/repository/org/ow2/asm/asm-analysis/9.5/asm-analysis-9.5.jar
[ERROR] urls[7] = file:/Users/rgoers/.m2/repository/org/apache/commons/commons-lang3/3.12.0/commons-lang3-3.12.0.jar
[ERROR] urls[8] = file:/Users/rgoers/.m2/repository/org/codehaus/plexus/plexus-utils/3.5.1/plexus-utils-3.5.1.jar
[ERROR] Number of foreign imports: 1
[ERROR] import: Entry[import from realm ClassRealm[maven.api, parent: null]]
[ERROR]
[ERROR] -----------------------------------------------------
Ralph
> On May 2, 2023, at 12:08 PM, Piotr P. Karwasz <pi...@gmail.com> wrote:
>
> The Apache Log4j Transformation Tools 0.1.0 release is now available for voting.
>
> This is the first release and it contains two modules:
>
> * [LOG4J2-3638]: Adds a bytecode transformation tool to provide
> location information without reflection.
> * [LOG4J2-673]: Adds a resource transformer for the Maven Shade Plugin
> to merge `Log4j2Plugins.dat` plugin caches. Thanks to Eduard
> Gizatullin.
>
> Changes between RC2 and RC3:
>
> * The `log4j-transform-maven-plugin` has a `includes/excludes` setting
> now (useful for benchmark testing),
> * There is a `log4j-transform-perf` module (not in the main reactor
> for a chicken and egg problem),
> * The release was fully automated (hence the 0.1.0-rc1 tag instead of
> 0.1.0-rc3 tag due to some differences between my bash and Github),
> * The source archive does not have Git and Github-related stuff (thanks Gary).
>
> Source repository: https://github.com/apache/logging-log4j-transform
> Tag: rel/0.1.0-rc1
> Commit: b49a898f74e1ceaa8cd883f211c0a9c30ef8f5c1
> Artifacts: https://dist.apache.org/repos/dist/dev/logging/log4j-transform/0.1.0
> Nexus repository:
> https://repository.apache.org/content/repositories/orgapachelogging-1106
> CI job run: https://github.com/apache/logging-log4j-transform/actions/runs/4864531191
> Signing key: https://keyserver.ubuntu.com/pks/lookup?search=077e8893a6dcc33dd4a4d5b256e73ba9a0b592d0&fingerprint=on&op=index
> Website: https://logging.staged.apache.org/log4j/2.x/log4j-transform
>
> Please download, test, and cast your votes on the Log4j developers list.
>
> [ ] +1, release the artifacts
> [ ] -1, don't release, because...
>
> The vote will remain open for 72 hours 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.
>
> Countdown: https://www.timeanddate.com/countdown/launch?iso=20230505T2115&p0=4162&msg=Log4j+Transformation+Tools+0.1.0&font=cursive
Re: [VOTE] (RC3) Release Apache Log4j Transformation Tools 0.1.0
Posted by "Piotr P. Karwasz" <pi...@gmail.com>.
Hi Volkan,
On Thu, 4 May 2023 at 09:09, Volkan Yazıcı <vo...@yazi.ci> wrote:
> (NOTICE file is missing, but not a blocker, AFAIC.)
META-INF/{DEPENDENCIES,LICENSE,NOTICE} are generated by the Apache
Maven Remote Resources plugin (courtesy of the ASF parent POM):
https://maven.apache.org/plugins/maven-remote-resources-plugin/index.html
The Velocity templates used to generate them can be found here:
https://github.com/apache/maven-apache-resources/tree/master/jar/src/main/resources/META-INF
The generated resources should probably be included into the source
archive (another reason to use `maven-assembly-plugin`). That is what
the ASF parent POM does.
Piotr
Re: [VOTE] (RC3) Release Apache Log4j Transformation Tools 0.1.0
Posted by Volkan Yazıcı <vo...@yazi.ci>.
+1
Verified signatures, checksums, and LICENSE files.
(NOTICE file is missing, but not a blocker, AFAIC.)
On Tue, May 2, 2023 at 9:09 PM Piotr P. Karwasz <pi...@gmail.com>
wrote:
> The Apache Log4j Transformation Tools 0.1.0 release is now available for
> voting.
>
> This is the first release and it contains two modules:
>
> * [LOG4J2-3638]: Adds a bytecode transformation tool to provide
> location information without reflection.
> * [LOG4J2-673]: Adds a resource transformer for the Maven Shade Plugin
> to merge `Log4j2Plugins.dat` plugin caches. Thanks to Eduard
> Gizatullin.
>
> Changes between RC2 and RC3:
>
> * The `log4j-transform-maven-plugin` has a `includes/excludes` setting
> now (useful for benchmark testing),
> * There is a `log4j-transform-perf` module (not in the main reactor
> for a chicken and egg problem),
> * The release was fully automated (hence the 0.1.0-rc1 tag instead of
> 0.1.0-rc3 tag due to some differences between my bash and Github),
> * The source archive does not have Git and Github-related stuff (thanks
> Gary).
>
> Source repository: https://github.com/apache/logging-log4j-transform
> Tag: rel/0.1.0-rc1
> Commit: b49a898f74e1ceaa8cd883f211c0a9c30ef8f5c1
> Artifacts:
> https://dist.apache.org/repos/dist/dev/logging/log4j-transform/0.1.0
> Nexus repository:
> https://repository.apache.org/content/repositories/orgapachelogging-1106
> CI job run:
> https://github.com/apache/logging-log4j-transform/actions/runs/4864531191
> Signing key:
> https://keyserver.ubuntu.com/pks/lookup?search=077e8893a6dcc33dd4a4d5b256e73ba9a0b592d0&fingerprint=on&op=index
> Website: https://logging.staged.apache.org/log4j/2.x/log4j-transform
>
> Please download, test, and cast your votes on the Log4j developers list.
>
> [ ] +1, release the artifacts
> [ ] -1, don't release, because...
>
> The vote will remain open for 72 hours 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.
>
> Countdown:
> https://www.timeanddate.com/countdown/launch?iso=20230505T2115&p0=4162&msg=Log4j+Transformation+Tools+0.1.0&font=cursive
>