Thanks for the explanation, it makes sense:
Patch acts more like an override than an append.
best,
Robert
On 3-4-2020 12:56:10, Alan Bateman <alan.bate...@oracle.com> wrote:
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
