JUnit AssertionError：在Maven中运行时无法识别平台

Question

I'm working to transition our project's build structure from Ant to Maven (3.3.3), using Java 1.8, and ran into an issue that's stumping me. All of our unit tests are working properly in Ant and Eclipse, but I've run into several that fail when executing in Maven. The failing tests (unfortunately, I can't post source due to corporate restrictions) all are attempting to read an image through the javax.imageio.ImageIO class, and all seem to fail with a NoClassDefFoundError, stating that they could not initialize java.nio.file.TempFileHelper. Now, I've seen this type of problem crop up when something is attempting to initialize the class, and fails (rather than not being able to find the class definition at all), but I looked into the source of the TempFileHelper class, and I can't seem to figure out what would have failed.

The stack trace (hand-typed, apologies for any typeos):

java.lang.NoClassDefFoundError: Could not initialize class java.nio.file.TempFileHelper
    at java.nio.file.Files.createTempFile(Files.java:897)
    at javax.imageio.stream.FileCacheImageInputStream.<init>(FileCacheImageInputStream.java:102)
    at com.sun.imageio.spi.InputStreamImageInputStreamSpi.createInputStreamInstance(InputStreamImageInputStreamSpi.java:69)
    at javax.imageio.ImageIO.createImageInputStream(ImageIo.java:357)
    at javax.imageio.ImageIO.read(ImageIO.java:1397)
    ... our code beyond here ...

The class making call to ImageIO.read is defined in a different maven module than the unit test (called core), and core has built successfully before this happens. The class making the call to ImageIO.read is supplying a relative path to a png file that is defined in core, and the image is stored in the resources folder of the core, under an "images" subfolder.

example, using foo.png as the filename:

core/src/main/resources/images/foo.png

URL imageUrl = SomeClass.class.getResource("/images/foo.png");
ImageIO.read(imageUrl);

I've verified that foo.png is in the core.jar after core has built, and is in the images folder immediately off of the root of the jar, and that the core module is a valid dependency of the module being tested.

Any help is greatly appreciated!

Update 1

While poking around through the TempFileHelper, I stumbled on some code that could fail, and brought it into my unit test to see if it continued to fail. The failure now seems to indicate that the default file system is not known, by way of the following stack trace:

java.lang.AssertionError: Platform not recognized
    at sun.nio.fs.DefaultSystemProvider.create(DefaultSystemProvider.java:68)
    ... our code truncated...

Update 2

Per Alexandre Cartapanis's request, here's the POM snippets. The project is multi-module, and the parent pom is using plugin management to control versions.

Parent POM snippet:

<build>
    <pluginManagement>
        <plugins>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-compiler-plugin</artifactId>
                <version>3.3</version>
                <configuration>
                    <source>1.8</source>
                    <target>1.8</target>
                </configuration>
            </plugin>
        </plugins>
    </pluginManagement>
</build>

Child POM snippet:

<build>
    <plugins>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-compiler-plugin</artifactId>
            <configuration>
                <source>1.8</source>
                <target>1.8</target>
                <compilerArgs>
                    <arg>-XDignore.symbol.file</arg>
                    <compilerArg>-XDignore.symbol.file</compilerArg>
                </compilerArgs>
                <fork>true</fork>
            </configuration>
        </plugin>
    </plugins>
</build>

Answer 1

After much searching around, I have discovered the problem. It seems that one of our developers had written a test that was resetting the os.name (to "testOs") and os.version system properties, and never resetting them to their former values. This caused all java.nio.Paths calls to fail.

I discovered this after looking at the source of the sun.nio.fs.DefaultFileSystemProvider class, which immediately told me what it was attempting to look for, and the expected values. After discovering this, and a good bit more googling, I dropped in a System.getProperty("os.name") and printed it out in one of the failing tests, leading me to find "testOs". After discovering that, it was just a matter of determining that no, Maven nor JUnit are setting the os.name to that value, and therefore, it must be in our code.

Thank you to everyone that attempted to help, your assistance is greatly appreciated.

Rob