It also just failed for me on my Mac. It got the same error on line 73.
Ralph
> On May 28, 2022, at 2:32 PM, Ralph Goers wrote:
>
> You need to mark a test you recently added as flaky as it has failed for me
> twice on Windows.
>
> [INFO]
> [ERROR] Failures:
> [ERROR] OnPropertyConditionTes
It worked, but I had to specify where the parent pom was in the submodules. Are
you saying I could get the same effect by importing the bom in the parent pom?
If so, that certainly seems easier.
—
Matt Sicker
> On May 28, 2022, at 18:15, Ralph Goers wrote:
>
> Why is this necessary? I would
Why is this necessary? I would think having the parent import the bom/pom.xml
should be enough.
Ralph
> On May 27, 2022, at 6:18 PM, Matt Sicker wrote:
>
> To avoid rearranging all the directories, I'm moving the parent pom to
> its own directory, moving the bom pom to the root, and updating t
You need to mark a test you recently added as flaky as it has failed for me
twice on Windows.
[INFO]
[ERROR] Failures:
[ERROR] OnPropertyConditionTest.whenPropertyMatches:80 expected: but
was:
[ERROR] OnPropertyConditionTest.whenPropertyPresent:73 expected: but
was:
Ralph
> On May 28,
And now that I just started working on Map> injection, I
see where this could would have otherwise been used. When streaming through
plugins, right now, all plugin classes in that namespace get loaded to at least
check their ordering annotations (another bit of metadata that could be indexed
no
Well, let’s take a look at the commits that have failed CI builds lately. Of
course CI was green before, MutableThreadContextMapFilterTest was only
introduced recently. Since then, the following completely unrelated commits
have CI build failures:
*
https://github.com/apache/logging-log4j2/com
There is only one flaw with that argument. When I did release 2.17.2 we weren’t
having random test failures like this. So something changed.
Ralph
> On May 28, 2022, at 11:34 AM, Matt Sicker wrote:
>
> Oh, and if these tests used to work, they wouldn’t be flaking from unrelated
> changes such
Oh, and if these tests used to work, they wouldn’t be flaking from unrelated
changes such as when someone updates a README file or other non-code area that
somehow results in a failed CI run.
—
Matt Sicker
> On May 28, 2022, at 10:29, Matt Sicker wrote:
>
> I sent a separate email complaining
Agreed on the OSGi requirements as that matches the Java baseline requirements.
As for the EE stuff, I’m less familiar with this area these days as the only EE
thing I really use anymore is Tomcat (as part of Spring Boot).
—
Matt Sicker
> On May 28, 2022, at 03:04, Piotr P. Karwasz wrote:
>
>
I sent a separate email complaining about how Dependabot does this. Anyways,
the disabled tests are flakes. As I’ve said before, I run the full build and
suite of tests locally before pushing commits, but I’ve been getting tons of
build failure emails regardless. So instead of ignoring CI failur
Hi Ralph,
On Sat, 28 May 2022 at 10:17, Ralph Goers
wrote:
> What I don’t understand is why several of the Jira issues seemingly have
> 100 commits on various branches and flooded my inbox with email.
>
> This is Dependabot-related: every time a commit with "LOG4J2" appears in
*any* branch, JIRA
Matt, it seems you have disabled a bunch of tests. I’ve been working on one
that I recently committed but for the life of me cannot figure out why it is
failing on Windows.
What I don’t understand is why several of the Jira issues seemingly have 100
commits on various branches and flooded my in
Hi,
Given the recent series of Dependabot proposals I was wondering what are
the baselines In Log4j2 for Java EE and OSGI technologies. We don't really
use them extensively, so we can tell Dependabot to stay at an older version
and don't propose any upgrades.
Given the cheat sheet at:
https://ww
13 matches
Mail list logo
