Das Ausführen von maven (3.5.2) eines Spring Boot 2.0.2.RELEASE-Antrags (generiert durch einen Webinitialisierer mit Webabhängigkeiten) schlägt fehl, wenn das maven-surefire-plugin ausgeführt wird:
Fehler: Die Hauptklasse konnte nicht gefunden oder geladen werden org.Apache.maven.surefire.booter.ForkedBooter
Verursacht durch: Java.lang. ClassNotFoundException : org.Apache.maven.surefire.booter. ForkedBooter
Warum passiert dies? Ist es ein Problem bei der Boot + Surefire-Integration = ein Fehler?
Zu Referenzzwecken scheinen folgende Abhängigkeiten relevant zu sein:
<parent>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-parent</artifactId>
<version>2.0.2.RELEASE</version>
<relativePath/>
</parent>
...
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-test</artifactId>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.unitils</groupId>
<artifactId>unitils</artifactId>
<version>2.2</version>
<scope>test</scope>
</dependency>
...
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>
...
<build>
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
</plugin>
</plugins>
</build>
Umgehung für dieses Problem war, die maven-surefire-plugin
-Definition von Spring Boot zu überschreiben und useSystemClassLoader
auf false
zu setzen. Lesen Sie Surefire docs für weitere Details
<build>
<plugins>
...
<plugin>
<groupId>org.Apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<configuration>
<useSystemClassLoader>false</useSystemClassLoader>
</configuration>
</plugin>
</plugins>
</build>
Die von jediz bereitgestellte <useSystemClassLoader>false</useSystemClassLoader>
-Lösung ermöglichte die Ausführung meiner todsicheren Tests, brach jedoch in einigen Spring Boot-Integrationstests das Klassenladen.
Die folgende Konfiguration des maven-surefire-plugins hat für mich funktioniert:
<plugin>
<groupId>org.Apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<configuration>
<argLine>-Djdk.net.URLClassPath.disableClassPathURLCheck=true</argLine>
</configuration>
</plugin>
Für mich bestand die Lösung darin, mvn als auszuführen
_Java_OPTIONS=-Djdk.net.URLClassPath.disableClassPathURLCheck=true mvn clean compile package
Andere Ideen (Übergeben der Systemeigenschaft an die Maven-Argumentliste, andere Änderungen in pom.xml
, settings.xml
) funktionierten nicht.
Obwohl es nicht die exakte Lösung enthielt, war diese Antwort sehr hilfreich für mich, um klar zu machen, dass es eine unglückliche Zusammenarbeit zweier unabhängiger, allein harmloser Fehler in Ubuntu JDK und Maven ist Surefire Plugin.
Aktuelle Debian (buster) mit der gleichen JDK- und Maven-Version scheinen nicht von dem Problem betroffen zu sein, Ubuntu (xenial) jedoch.
Die genaue Lösung kommt von this answer.
Die Aktualisierung des maven-surefire-plugins von 2.12.4 auf 3.0.0-M1 hat für mich funktioniert. Das Projekt hat das Plugin nicht explizit verwendet, daher musste ich eine neue Plugin-Abhängigkeit hinzufügen.
<plugins>
...
<plugin>
<artifactId>maven-surefire-plugin</artifactId>
<version>3.0.0-M1</version>
</plugin>
...
</plugins>
Ich konnte das maven-surefire-plugin aus meinem POM entfernen, nachdem ich es oben in meinem POM hinzugefügt hatte (im <project>
-Knoten).
<prerequisites>
<maven>3.6.0</maven>
</prerequisites>
Warum finde ich das die richtige Antwort?
mvn versions:display-plugin-updates
ausführen, zeigt dies an, dass es das maven-surefire-plugin 3.0.0-M3 von super-pom nimmt, was bisher anscheinend dieses Problem behoben hat.