This vote has passed with 3 binding +1 votes from Matt Sicker, Remko Popma and
Ralph Goers, 1 binding +0 vote from Gary Gregory, and a +1 vote from Volkan
Yazici.
I will continue with the release process.
Ralph
I welcome the move to JUnit 5. :-)
On Mon, 9 Nov 2020 at 18:33, Matt Sicker wrote:
> This is in the new test framework. I may have missed an edge case while
> porting over tests since I haven’t finished that yet (got side tracked by
> some issues raised in the rolling appender code, then some ot
I found it much easier to parallelize the tests in the API module so far
which seems to help with build times. There’s far more flexibility in 5,
especially for combining extensions which was historically very hard.
On Mon, Nov 9, 2020 at 12:51 Gary Gregory wrote:
> Thanks for the update Matt. Y
Thanks for the update Matt. Yeah Junit 4 and 5 are surprisingly different.
I hope 5 is really better.
Gary
On Mon, Nov 9, 2020, 13:33 Matt Sicker wrote:
> This is in the new test framework. I may have missed an edge case while
> porting over tests since I haven’t finished that yet (got side tra
I will note that the test you highlighted is one that frequently fails in
CI, so that looks like a good investigation point.
On Mon, Nov 9, 2020 at 12:33 Matt Sicker wrote:
> This is in the new test framework. I may have missed an edge case while
> porting over tests since I haven’t finished tha
This is in the new test framework. I may have missed an edge case while
porting over tests since I haven’t finished that yet (got side tracked by
some issues raised in the rolling appender code, then some other items).
I’ve been adapting our test tooling to use the JUnit 5 extension API which
is fa
Matt & all:
The last failing test I have on Windows fails, always, from the Maven
command line or Eclipse:
> > > [ERROR] Failures:
> > > [ERROR] FileOutputTest.testConfig target\status.log failed with
> > > java.nio.file.FileSystemException: target\status.log: The process
> cannot
> > > access th
Hi,
I just fixed one test issue:
in RandomAccessFileManagerTest.testAppendDoesNotOverwriteExistingFile
One more to go.
Gary
On Mon, Nov 9, 2020, 10:24 Ralph Goers wrote:
> Gary,
>
> If you find that the Windows issues are not problems in the tests please
> let us know as that could be conside
See also https://issues.apache.org/jira/browse/LOG4J2-2923
On Mon, 9 Nov 2020 at 09:04, wrote:
>
> This is an automated email from the ASF dual-hosted git repository.
>
> ggregory pushed a commit to branch release-2.x
> in repository https://gitbox.apache.org/repos/asf/logging-log4j2.git
>
>
> Th
Gary,
If you find that the Windows issues are not problems in the tests please let us
know as that could be considered a blocker. But if you can find and fix the
problems to the tests that would be appreciated. If not, I can try to do it
when I get spare cycles to run it in a VM.
Ralph
> On
I found a way to fix the test failure on my Mac mini in TestConfigurator by
increasing sleep times and committed that to release-2.x. So now my Mac
build is completed with 'mvn clean install' :-)
Windows still fails as noted previously and I'll see if I have time to look
into failures before the 7
It seems that I missed the test execution aspect in my original analysis.
That is indeed a blocker. I’d be open to requiring Java 11 if we can make
it easier to maintain and release 2.x concurrently. I’ve been trying to use
Java 11 (or whatever the latest release is at the time; 15 right now) by
de
12 matches
Mail list logo
