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!

[jhoeller]

We suppress NoSuchFileException next to the already suppressed FileNotFoundException for non-existing jar resources now.

This is available in the latest 6.2.7 snapshot. Please give it an early try!

[bbortt]

@jhoeller I fail to test the SNAPSHOT..

commit: bbortt/spring-core-34764-reproducer@35c703a

[ERROR] Failed to execute goal on project main-class: Could not collect dependencies for project io.github.bbortt:main-class:jar:1.0.0-SNAPSHOT
[ERROR] Failed to read artifact descriptor for org.springframework:spring-core:jar:6.2.7-SNAPSHOT
[ERROR]         Caused by: The following artifacts could not be resolved: org.springframework:spring-core:pom:6.2.7-SNAPSHOT (absent): Could not transfer artifact org.springframework:spring-core:pom:6.2.7-SNAPSHOT from/to maven-default-http-blocker (http://0.0.0.0/): Blocked mirror for repositories: [repository.spring.snapshot (http://repo.spring.io/snapshot, default, releases+snapshots)]         

am I doing something obviously wrong?

[jhoeller]

That's odd because it is definitely there:
https://repo.spring.io/ui/native/snapshot/org/springframework/spring-core/6.2.7-SNAPSHOT/

What does that "Blocked mirror" part of the error message mean?

[bbortt]

I've no clue. I did it on my private laptop, so there shouldn't be any firewall in the way.