wake-up-neo.com

Spring Boot kann Maven-Surefire-Plugin ClassNotFoundException org.Apache.maven.surefire.booter.ForkedBooter nicht ausführen

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>
45
jediz

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>
110
jediz

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>
15

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.

10
peterh

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>
7
rvange

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?

  • Es gibt die Version von Maven an, die von Maven empfohlen wird: https://maven.Apache.org/download.cgi
  • wenn Sie 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.
  • Sie müssen die einzelnen Plugin-Versionen nicht unabhängig voneinander verwalten. Nur Ihre minimale Maven-Version, die die Super-Pom-Version steuert.
0
GlenPeterson