本文介紹了JUnit AssertionError:在Maven中運(yùn)行時(shí)無(wú)法識(shí)別平臺(tái)的處理方法,對(duì)大家解決問(wèn)題具有一定的參考價(jià)值,需要的朋友們下面隨著小編來(lái)一起學(xué)習(xí)吧!
問(wèn)題描述
我正在使用Java 1.8將我們項(xiàng)目的構(gòu)建結(jié)構(gòu)從Ant轉(zhuǎn)換到Maven(3.3.3),但我遇到了一個(gè)令我困惑的問(wèn)題。我們的所有單元測(cè)試在Ant和Eclipse中都能正常工作,但我遇到過(guò)幾個(gè)在Maven中執(zhí)行失敗的單元測(cè)試。失敗的測(cè)試(不幸的是,由于公司的限制,我不能發(fā)布源代碼)都試圖通過(guò)javax.Imageio.ImageIO類(lèi)讀取圖像,并且似乎都失敗了,并顯示NoClassDefFoundError,聲明它們無(wú)法初始化java.nio.file.TempFileHelper?,F(xiàn)在,我已經(jīng)看到當(dāng)某個(gè)東西試圖初始化類(lèi)并失敗時(shí)會(huì)突然出現(xiàn)這種類(lèi)型的問(wèn)題(而不是根本找不到類(lèi)定義),但我查看了TempFileHelper類(lèi)的源代碼,我似乎找不出會(huì)失敗的是什么。
堆棧跟蹤(手動(dòng)鍵入,請(qǐng)?jiān)徣魏晤?lèi)型的人):
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 ...
調(diào)用ImageIO.read的類(lèi)是在與單元測(cè)試(稱(chēng)為core)不同的maven模塊中定義的,并且core在此之前已經(jīng)成功構(gòu)建。調(diào)用ImageIO.Read的類(lèi)提供了核心中定義的PNG文件的相對(duì)路徑,圖像存儲(chǔ)在核心的Resources文件夾中的”Images”子文件夾下。
示例,使用foo.png作為文件名:
core/src/main/resources/images/foo.png
URL imageUrl = SomeClass.class.getResource("/images/foo.png");
ImageIO.read(imageUrl);
我已經(jīng)驗(yàn)證了,在構(gòu)建核心之后,foo.png位于core.jar中,并且位于JAR根目錄下的圖像文件夾中,并且核心模塊是正在測(cè)試的模塊的有效依賴(lài)項(xiàng)。
非常感謝您的幫助!
更新%1
在瀏覽TempFileHelper時(shí),我無(wú)意中發(fā)現(xiàn)了一些可能失敗的代碼,并將其帶入單元測(cè)試,以查看它是否繼續(xù)失敗。通過(guò)以下堆棧跟蹤,該失敗現(xiàn)在似乎表明默認(rèn)文件系統(tǒng)未知:
java.lang.AssertionError: Platform not recognized
at sun.nio.fs.DefaultSystemProvider.create(DefaultSystemProvider.java:68)
... our code truncated...
更新2
根據(jù)Alexandre Carcapanis的請(qǐng)求,以下是POM片段。該項(xiàng)目是多模塊的,父POM使用插件管理來(lái)控制版本。
父POM代碼段:
<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>
子POM代碼段:
<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>
推薦答案
我到處找了很久,才發(fā)現(xiàn)這個(gè)問(wèn)題。我們的一位開(kāi)發(fā)人員似乎編寫(xiě)了一個(gè)測(cè)試,將os.name(設(shè)置為”Testos”)和os.version系統(tǒng)屬性重置,但從未將它們重置為以前的值。這會(huì)導(dǎo)致所有的java.nio.Path調(diào)用失敗。
我在查看sun.nio.fs.DefaultFileSystemProvider類(lèi)的源代碼后發(fā)現(xiàn)了這一點(diǎn),它立即告訴我它試圖查找的內(nèi)容和期望值。在發(fā)現(xiàn)這一點(diǎn)后,并進(jìn)行了更多的谷歌搜索,我插入了一個(gè)System.getProperty(“os.name”),并在其中一個(gè)失敗的測(cè)試中將其打印出來(lái),導(dǎo)致我找到了”Testos”。在發(fā)現(xiàn)這一點(diǎn)之后,只需確定no、Maven或JUnit正在將os.name設(shè)置為該值,因此,它一定在我們的代碼中。
感謝所有試圖提供幫助的人,我們非常感謝您的幫助。
Rob
這篇關(guān)于JUnit AssertionError:在Maven中運(yùn)行時(shí)無(wú)法識(shí)別平臺(tái)的文章就介紹到這了,希望我們推薦的答案對(duì)大家有所幫助,