On 03/04/2020 10:17, Robert Scholte wrote:
This issue was registered as SUREFIRE-1768[1]
It contains a very small Maven project to demonstrate the issue.
That project contains one method executing the following:
Demo.class.getClassLoader().getResources("demo").asIterator().forEachRemaining(url
-> {
System.out.println(url.getFile()); // I'd like to see the
target/classes/demo directory here at some point.
});
After executing the test it shows the following result
/E:/test-classpath-demo-master/target/test-classes/demo/
/E:/test-classpath-demo-master/target/test-classes/demo
these are similar, but more worrying: where is
/E:/test-classpath-demo-master/target/classes/demo
I rewrote it a bit by including a main method to ensure it is not caused by
surefire:
"%JAVA_HOME%"\bin\java --module-path target/classes --patch-module
test.classpath.demo=target/test-classes --module test.classpath.demo/demo.DemoTest
this gave me only one result (where I expected 2):
/E:/test-classpath-demo-master/target/test-classes/demo/
So the question is, where is
/E:/test-classpath-demo-master/target/classes/demo/
Patching is to used to replace specific classes or resources in a module
with alternative versions. It can also be used to augment a module with
new classes or resources. In the reproducer, it looks like module
test.classpath.demo has been patched so that "demo" is found in the
patch rather than the original module. This is correct behavior.
If it helps, this will give a list of the resources in the module so you
can see the effect of the patching:
String name = this.getClass().getModule().getName();
ModuleLayer.boot()
.configuration()
.findModule(name)
.orElseThrow()
.reference()
.open()
.list()
.forEach(System.out::println)
-Alan
