I am not proposing to implement this right now. All I am after is an
agreement. Indeed we should pursue this route once staging is back to
normal.
On Mon, Oct 23, 2023 at 2:05 AM Christian Grobmeier
wrote:
>
>
> On Sun, Oct 22, 2023, at 21:54, Volkan Yazıcı wrote:
> > It has been a long thread a
+1
Fix the staging site. Defer talk about anything else until that is done.
Ralph
> On Oct 22, 2023, at 5:05 PM, Christian Grobmeier wrote:
>
>
>
>> On Sun, Oct 22, 2023, at 21:54, Volkan Yazıcı wrote:
>> It has been a long thread and I want to capture the result: *there are no
>> objection
I am ok with 1 and 2, but not 3. Doing that means older releases web sites are
no longer available. Just because the latest includes release notes for all
versions doesn’t mean it fully documents what was in prior releases. However, I
am not surprised you are suggesting this as I posted in an ea
> it [doesn't] fully documents what was in prior releases
Why is this a problem? We document newly added features with "starting from
version X, Log4j ships Y...". Doesn't this address your concern?
Many projects follow this convention, even Java itself:
https://docs.oracle.com/en/java/javase/ind
Staging website has been broken since October 10, that is, the last two
weeks – please, correct me if I'm wrong. I support Christian's Jekyll
migration and I know he is blocked by INFRA.
1. Do we have a deadline to consider alternative courses of action?
2. Can we implement your Jekyll goal
Hi Volkan,
On Mon, 23 Oct 2023 at 10:40, Volkan Yazıcı wrote:
>
> > it [doesn't] fully documents what was in prior releases
>
> Why is this a problem? We document newly added features with "starting from
> version X, Log4j ships Y...". Doesn't this address your concern?
I prefer to document each
+1
Tested it with our product and works flawlessly where 2.20.0 failed
On 2023/10/20 21:20:00 "Piotr P. Karwasz" wrote:
> This is a vote to release the Apache Log4j 2.21.1.
>
> Website: https://logging-log4j2.staged.apache.org/log4j
> GitHub: https://github.com/apache/logging-log4j2
> Commit: e61
Agreed, we should use `@since` tags. Though this doesn't warrant a new
website folder for each release, does it? Given we never disclosed these
folders, I want to understand the value it delivered in the past that can't
be achieved if we switch to using a single folder.
On Mon, Oct 23, 2023 at 12:
I reran again yesterday, got the same 2 failures we know about plus a new one:
[ERROR] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 6.236 s
<<< FAILURE! -- in org.apache.logging.log4j.core.config.FileOutputTest
[ERROR] org.apache.logging.log4j.core.config.FileOutputTest.testCon
Hi
On Mon, Oct 23, 2023, at 11:01, Volkan Yazıcı wrote:
> Staging website has been broken since October 10, that is, the last two
> weeks – please, correct me if I'm wrong. I support Christian's Jekyll
> migration and I know he is blocked by INFRA.
I have created the issue only 5 days ago, after
Hi Gary,
On Mon, 23 Oct 2023 at 13:33, Gary D. Gregory wrote:
>
> I reran again yesterday, got the same 2 failures we know about plus a new one:
Parallel tests on Windows must be worse than I imagined. Can you run
with `-Psequential-tests` in the meantime and I'll try to fix those
problems in a
On Mon, Oct 23, 2023 at 8:10 AM Piotr P. Karwasz
wrote:
>
> Hi Gary,
>
> On Mon, 23 Oct 2023 at 13:33, Gary D. Gregory wrote:
> >
> > I reran again yesterday, got the same 2 failures we know about plus a new
> > one:
>
> Parallel tests on Windows must be worse than I imagined. Can you run
> with
+1
Windows is running on my other PC but all is well on macOS with 'mvn
clean verify' using:
Apache Maven 3.9.5 (57804ffe001d7215b5e7bcb531cf83df38f93546)
Maven home: /usr/local/Cellar/maven/3.9.5/libexec
Java version: 11.0.21, vendor: Homebrew, runtime:
/usr/local/Cellar/openjdk@11/11.0.21/libex
Does not matter, running "mvn clean verify -Psequential-tests", I still get:
[ERROR] Failures:
[ERROR] UrlConnectionFactoryTest.withAuthentication:130 File was not modified
==> expected: <200> but was: <304>
[INFO]
[ERROR] Tests run: 2774, Failures: 1, Errors: 0, Skipped: 35
Gary
On 2023/10/2
I think #2 would be necessary when we start doing concurrent releases of
the same project; e.g., Log4j `2.34.0` and `3.2.0`. I really liked the
single-use staging domains *you* proposed due to the conveniences it
enables and I would rather keep it.
On Mon, Oct 23, 2023 at 2:03 PM Piotr P. Karwasz
Staying from the built-in Service Loader is a recipe for even more
custom code and complications. I say we stick with the built-in
Service Loader.
Gary
On Sun, Oct 22, 2023 at 5:01 PM Piotr P. Karwasz
wrote:
>
> Hi Matt,
>
> On Sun, 22 Oct 2023 at 22:49, Matt Sicker wrote:
> > So now we come to
So really, the question is whether we can make the generated service classes
easier to create without annotation processing?
> On Oct 23, 2023, at 12:11 PM, Gary Gregory wrote:
>
> Staying from the built-in Service Loader is a recipe for even more
> custom code and complications. I say we stick
We really don’t have much choice. With JPMS you really need to use
ServiceLoader to locate things like plugins across modules. Using a s file like
spring.factories doesn’t really help anyway. You wouldn’t want to force users
to hand create the entries in that file and so would use annotations an
Considering I’m one of the only people who adds @since tags (or Javadocs in
general), I think we’ll need some tooling to help with this. In Jenkins, we had
some sort of script for this so that we could add “@since TODO” to new files,
and the script would replace them all before tagging a release
Adding my +1.
With that, the release passes with 3 binding +1 votes from Gary
Gregory, Volkan Yazıcı, and me. An additional non-binding +1 was cast
by Fritz Lumnitz.
I will therefore continue the release process.
Piotr
On Fri, 20 Oct 2023 at 23:20, Piotr P. Karwasz wrote:
>
> This is a vote to
20 matches
Mail list logo
