As usual, as soon as I take the time to write the email, I seem to find a solution shortly after that ...
So, it seems that I managed to load the resource by changing: this.testsuiteDocumentXml = getClass().getResourceAsStream(testsuiteDocument); To: this.testsuiteDocumentXml = getClass().getClassLoader().getUnnamedModule().getResourceAsStream(testsuiteDocument); I think this is probably just a workaround and I am not quite sure about the implications. So, it this the way to go, or is there a prettier way to fix this? Chris -----Original Message----- From: Christofer Dutz Sent: Donnerstag, 27. Januar 2022 22:59 To: Maven Users List <users@maven.apache.org> Subject: RE: Problems with the maven-failsafe-plugin and loading of resources from (test-)jars Sorry for the double posting ... guess my mailserver had hickups and now I know why I had to write it twice 😉 I think this version might be the better one .. Chris -----Original Message----- From: Christofer Dutz <christofer.d...@c-ware.de> Sent: Donnerstag, 27. Januar 2022 22:57 To: Maven Users List (users@maven.apache.org) <users@maven.apache.org> Subject: Problems with the maven-failsafe-plugin and loading of resources from (test-)jars Hi, in the Apache PLC4X build we recently noticed that surefire and failsafe 2.22.2 were missing to pickup some of our tests, which we use with @TestFactory annotation. It turns out that when switching to 3.0.0-M5 this problem is resolved. However, a new problem is now causing problems. In our tests we usually load test-jars which contain test-resources which are processed in our tests. They are referenced by the module in this way: <dependency> <groupId>org.apache.plc4x</groupId> <artifactId>plc4x-protocols-modbus</artifactId> <version>0.10.0-SNAPSHOT</version> <classifier>tests</classifier> <type>test-jar</type> <scope>test</scope> </dependency> In failsafe the test is unable to load the resources. If I run the identical test in surefire, it works. If I run it in failsafe 2.22.2, it works. In the IDE the tests also work fine. So, I did some debugging and could see that the classloader used to load the resources correctly contains the jar that contains the resources in its URLClassPath, however the Classloader doesn't seem to use this. Anyone got an idea what's going on? Thanks, Chris