I ran it multiple times in my Windows VM and it failed each time. I am not going to hunt down what directories I need to be deleting. The test needs to do that. Since H2 is only used for testing I don’t consider it a big deal. The link you provided clearly shows it is a test dependency so almost no-one will care.
But if you want to fix the failing test I am OK with that. I should point out though that this is the poster boy for why we need to break up Log4j into multiple repos. Or rather, LOG4J2-3428 makes it clear why. It shows 36 dependencies being upgraded since 2.17.2 was released. I am betting most of them are test dependencies but still, with that many dependencies updated the likelihood of problems goes way up. Ralph > On May 29, 2022, at 11:54 PM, Piotr P. Karwasz <[email protected]> > wrote: > > Hi Ralph, > > On Mon, 30 May 2022 at 00:26, Ralph Goers <[email protected]> > wrote: > >> FWIW, the h2 upgrade broke the build. I am in the process of reverting the >> version change. >> >> Ralph >> > > I would really like the H2 upgrade to be included in 2.18.0, so that pages > like this: > > https://mvnrepository.com/artifact/org.apache.logging.log4j/log4j-core/2.17.2 > > don't have any red notices. > > As I explained in another e-mail, the failure of the test is due to the > fact that the test leaves garbage in the temporary directory. When you > switch from H2 1.x to H2 2.x the test tries to load the leftovers of the > previous execution of the test and fails. > > After 2.18.0 I can find all tests to pinpoint those that leave files in the > filesystem. Since Surefire runs each test in a separate JVM, I believe that > by correcting the misbehaving tests, we will be able to run tests in > parallel. > > Piotr
