PathMatchingResourcePatternResolver wrongly assumes that target/classes always exists

[bbortt]

What I think is a bug has been introduced in [email protected].

The problem didn't occur in [email protected]. I did see some changes to PathMatchingResourcePatternResolver in the latest release, but fail to grasp how that would be related.

What is wrong in my opinion...

Assuming that a Maven project always has a target/classes folder present is wrong in my humble opinion. E.g. I personally like to create "integration test modules" for properly testing Spring autoconfigurations. These do only contain a target/test-classes folder.

More Context

The following fails now, and didn't before:

    public static void main(final String[] args) throws IOException {
        var resources = new PathMatchingResourcePatternResolver()
                .getResources("classpath*:**/*Test.xml");

        assertThat(resources)
                .hasSize(1);
    }

It produces the following stacktrace.

java.nio.file.NoSuchFileException: [REDACTED]\spring-core-bug-reproducer\integration-test\target\classes
    at sun.nio.fs.WindowsException.translateToIOException (WindowsException.java:85)
    at sun.nio.fs.WindowsException.rethrowAsIOException (WindowsException.java:103)
    at sun.nio.fs.WindowsException.rethrowAsIOException (WindowsException.java:108)
    at sun.nio.fs.WindowsFileAttributeViews$Basic.readAttributes (WindowsFileAttributeViews.java:53)
    at sun.nio.fs.WindowsFileAttributeViews$Basic.readAttributes (WindowsFileAttributeViews.java:38)
    at sun.nio.fs.WindowsFileSystemProvider.readAttributes (WindowsFileSystemProvider.java:197)
    at java.nio.file.Files.readAttributes (Files.java:1853)
    at java.util.zip.ZipFile$Source.get (ZipFile.java:1445)
    at java.util.zip.ZipFile$CleanableResource.<init> (ZipFile.java:724)
    at java.util.zip.ZipFile.<init> (ZipFile.java:251)
    at java.util.zip.ZipFile.<init> (ZipFile.java:180)
    at java.util.jar.JarFile.<init> (JarFile.java:345)
    at sun.net.www.protocol.jar.URLJarFile.<init> (URLJarFile.java:100)
    at sun.net.www.protocol.jar.URLJarFile.getJarFile (URLJarFile.java:69)
    at sun.net.www.protocol.jar.JarFileFactory.get (JarFileFactory.java:177)
    at sun.net.www.protocol.jar.JarURLConnection.connect (JarURLConnection.java:109)
    at sun.net.www.protocol.jar.JarURLConnection.getJarFile (JarURLConnection.java:70)
    at org.springframework.core.io.support.PathMatchingResourcePatternResolver.doFindPathMatchingJarResources (PathMatchingResourcePatternResolver.java:844)
    at org.springframework.core.io.support.PathMatchingResourcePatternResolver.findPathMatchingResources (PathMatchingResourcePatternResolver.java:713)
    at org.springframework.core.io.support.PathMatchingResourcePatternResolver.getResources (PathMatchingResourcePatternResolver.java:351)
    at io.github.bbortt.spring.reproducer.ClassPathResolverTest.main (ClassPathResolverTest.java:13)
    at org.codehaus.mojo.exec.ExecJavaMojo.doMain (ExecJavaMojo.java:375)
    at org.codehaus.mojo.exec.ExecJavaMojo.doExec (ExecJavaMojo.java:364)
    at org.codehaus.mojo.exec.ExecJavaMojo.lambda$execute$0 (ExecJavaMojo.java:286)
    at java.lang.Thread.run (Thread.java:1583)

Reproducer

There you go: https://github.com/bbortt/spring-core-34764-reproducer.

I would be open to help with solving the case, if someone can point me into a direction 😉 also, if you think that change in behavior is intended, please let me know!