Hi,
On Fri, Apr 3, 2020 at 11:18 AM Robert Scholte <rfscho...@apache.org> 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/
ModulePatcher.PatchedModuleReader.find(String name) does this:
Resource r = findResourceInPatch(name);
if (r != null) {
URI uri = URI.create(r.getURL().toString());
return Optional.of(uri);
} else {
return delegate().find(name);
}
where delegate() returns the non-patched part of the module.
So it either returns one, or the other.
While debugging, I set r=null to see what the delegate would find, and
it does find /E:/test-classpath-demo-master/target/classes/demo/
--
Simone Bordet
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless. Victoria Livschitz
