Maven todsicher konnte die ForkedBooter-Klasse nicht finden

Als ich kürzlich zu einem neuen Projekt kam, versuche ich, unseren Quellcode zu kompilieren. Gestern hat alles gut funktioniert, aber heute ist eine andere Geschichte.

Jedes Mal mvn clean install, wenn ich auf einem Modul laufe und die Tests erreiche, stürzt ein Fehler ab:

[INFO] --- maven-surefire-plugin:2.18.1:test (default-test) @ recorder ---
[INFO] Surefire report directory: /lhome/code/recorder/target/surefire-reports
[INFO] Using configured provider org.apache.maven.surefire.junitcore.JUnitCoreProvider
[INFO] parallel='none', perCoreThreadCount=true, threadCount=0, useUnlimitedThreads=false, threadCountSuites=0,     threadCountClasses=0, threadCountMethods=0, parallelOptimized=true

-------------------------------------------------------
 T E S T S
-------------------------------------------------------
Error: Could not find or load main class org.apache.maven.surefire.booter.ForkedBooter

Results :

Tests run: 0, Failures: 0, Errors: 0, Skipped: 0

und später:

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:2.18.1:test (default-test) on project recorder: Execution default-test of goal org.apache.maven.plugins:maven-surefire-plugin:2.18.1:test failed: The forked VM terminated without properly saying goodbye. VM crash or System.exit called?

Ich verwende Debian 9 (Stretch) 64-Bit mit OpenJDK 1.8.0_181, Maven 3.5.4 und arbeite hinter meinem Firmen-Proxy, den ich in meinem konfiguriert habe ~/.m2/settings.xml.

Eine seltsame Sache ist, dass die neueste Surefire-Version 2.22.1 ist, wenn ich mich richtig erinnere. Ich habe versucht, die Plugin-Version anzugeben, sie wird jedoch nicht aktualisiert. Andernfalls gibt es in keinem POM (Elternteil, Großelternteil oder diesem) eine Plugin-Versionsspezifikation .

Ich habe es geschafft, Maven zu zwingen, die Surefire-Version auf die neueste zu ändern, aber jetzt ist es noch schlimmer:

[INFO] -------------------------------------------------------
[INFO]  T E S T S
[INFO] -------------------------------------------------------
[INFO]
[INFO] Results:
[INFO]
[INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0

[...]

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:2.22.1:test (default-test) on project recorder:     There are test failures.
[ERROR]
[ERROR] Please refer to /lhome/code/recorder/target/surefire-reports for the individual test results.
[ERROR] Please refer to dump files (if any exist) [date].dump, [date]-jvmRun[N].dump and [date].dumpstream.
[ERROR] The forked VM terminated without properly saying goodbye. VM crash or System.exit called?
[ERROR] Command was /bin/sh -c cd /lhome/code/recorder/ && /usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java     '-javaagent:/lhome1/johndoe/.m2/repository/org/jacoco/org.jacoco.agent/0.7.4.201502262128/org.jacoco.agent-0.7.4.201502262128-runt    ime.jar=destfile=/lhome/code/recorder/target/jacoco.exec,append=true,includes=esa/*,excludes=**/api/**/*.class' -jar     /lhome/code/recorder/target/surefire/surefirebooter7426165516226884923.jar /lhome/code/recorder/target/surefire     2018-10-26T16-16-12_829-jvmRun1 surefire1721866559613511529tmp surefire_023400764142672144tmp
[ERROR] Error occurred in starting fork, check output in log
[ERROR] Process Exit Code: 1
[ERROR] org.apache.maven.surefire.booter.SurefireBooterForkException: The forked VM terminated without properly saying goodbye.     VM crash or System.exit called?
[ERROR] Command was /bin/sh -c cd /lhome/code/recorder/ && /usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java     '-javaagent:/lhome1/johndoe/.m2/repository/org/jacoco/org.jacoco.agent/0.7.4.201502262128/org.jacoco.agent-0.7.4.201502262128-runt    ime.jar=destfile=/lhome/code/recorder/target/jacoco.exec,append=true,includes=esa/*,excludes=**/api/**/*.class' -jar     /lhome/code/recorder/target/surefire/surefirebooter7426165516226884923.jar /lhome/code/recorder/target/surefire     2018-10-26T16-16-12_829-jvmRun1 surefire1721866559613511529tmp surefire_023400764142672144tmp
[ERROR] Error occurred in starting fork, check output in log
[ERROR] Process Exit Code: 1
[ERROR]     at org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:669)
[ERROR]     at org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:282)
[ERROR]     at org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:245)
[ERROR]     at org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1183)
[ERROR]     at     org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:1011)
[ERROR]     at org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:857)
[ERROR]     at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:137)
[ERROR]     at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
[ERROR]     at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:154)
[ERROR]     at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:146)
[ERROR]     at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
[ERROR]     at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
[ERROR]     at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:56)
[ERROR]     at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
[ERROR]     at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:305)
[ERROR]     at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:192)
[ERROR]     at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:105)
[ERROR]     at org.apache.maven.cli.MavenCli.execute(MavenCli.java:954)
[ERROR]     at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
[ERROR]     at org.apache.maven.cli.MavenCli.main(MavenCli.java:192)
[ERROR]     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[ERROR]     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
[ERROR]     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[ERROR]     at java.lang.reflect.Method.invoke(Method.java:498)
[ERROR]     at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
[ERROR]     at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
[ERROR]     at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
[ERROR]     at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)

Um dies zu beheben (im Jahr 2018), aktualisieren Sie Ihr openjdk auf die neueste Version, mindestens 8u191-b12. Falls dieses Problem im Jahr 2020 erneut auftritt, wurde wahrscheinlich das Standardverhalten von openjdk geändert, und Sie müssen dann das todsichere Maven-Plugin aktualisieren.

Dies war ein jetzt behobener Fehler im openjdk-8-Paket (Verhalten weicht erheblich vom Upstream ab, ohne dass dies erforderlich ist; es fehlt der Upstream-Patch, um wieder eine Sicherheitsüberprüfung zu deaktivieren), auf den Sie gerade aktualisiert haben. Es ist aber auch ein Fehler im todsicheren Plugin SUREFIRE-1588 , der angeblich in safefire 3.0.0-M1 behoben wurde : Es verwendet anscheinend absolute Pfade an einem Ort, an dem Java in Zukunft nur relative Pfadnamen zulässt (und Debian aktivierte das zukünftiges Verhalten bereits).

In der Paketversion 8u181-b13-2 heißt es:

• Wenden Sie Patches aus dem Sicherheitsupdate 8u191-b12 an.

Beachten Sie, dass 191-b12! = 181-b13. Die 191-b12-Sicherheitspatches wurden erst vor wenigen Tagen veröffentlicht, und anscheinend wollten die Betreuer sie schnell zu Ihnen bringen. Ein vollständiges Update auf 191-b12 erfordert wahrscheinlich zusätzliche Tests (nun, sollte diesen Upload anscheinend haben).

Es gab mehrere Problemumgehungen:

1. Sie können das vorherige Paket stattdessen von snapshots.do installieren . Nach dem Downgrade können Sie die fehlerhafte Version (wenn Sie aptitude verwenden und nicht apt) mit verbieten sudo aptitude forbid-version openjdk-8-jre-headless. Für reguläres "apt" habe ich keinen ähnlichen Verbotsmechanismus gesehen, daher müssten Sie wahrscheinlich apt pinning verwenden, um zu verhindern, dass dieses Upgrade erneut installiert wird (oder Sie führen einfach ein erneutes Downgrade durch, ich hoffe, dass dies bald behoben wird).
2. Laut Bug Tracking sollte es auch hilfreich sein , die Eigenschaft -Djdk.net.URLClassPath.disableClassPathURLCheck=truemit einer der üblichen Methoden (z. B. JAVA_FLAGS) festzulegen. Aber ich habe das selbst nicht überprüft. Sie können anscheinend sogar die Problemumgehung hinzufügen~/.m2/settings.xml , um sie problemlos für alle Ihre Maven-Builds zu aktivieren.

Wie Sie sehen können, funktioniert die Fehlerverfolgung , das Problem wurde eingegrenzt und ein festes Paket ist verfügbar. Eine neue Version des todsicheren Plugins wird in Kürze verfügbar sein!

Setzen Sie useSystemClassloader auf false:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-surefire-plugin</artifactId>
    <configuration>
        <useSystemClassLoader>false</useSystemClassLoader>
    </configuration>
</plugin>

Wenn Sie nicht von einem übergeordneten Element erben, für das eine Version definiert wurde (z. B. der Spring Boot-Starter), müssen Sie dies ebenfalls definieren.

Ich habe diese Problemumgehung gefunden und meine Tests behoben: Konfigurieren Sie den maven-surefire-pluginSystemklassenlader so, dass er nicht verwendet wird.

Ich habe eine andere Problemumgehung. Legen Sie die Umgebungsvariable _JAVA_OPTIONS fest. Ich habe dies für unsere TeamCity-Build-Agenten verwendet und jetzt laufen unsere Builds einwandfrei.

_JAVA_OPTIONS=-Djdk.net.URLClassPath.disableClassPathURLCheck=true

Ich habe eine gezieltere Variante einer der oben genannten Problemumgehungen in JIRA veröffentlicht . Hinzufügen zu ~/.m2/settings.xml:

<profile>
    <id>SUREFIRE-1588</id>
    <activation>
        <activeByDefault>true</activeByDefault>
    </activation>
    <properties>
        <argLine>-Djdk.net.URLClassPath.disableClassPathURLCheck=true</argLine>
    </properties>
</profile>

Ich hatte dieses Problem in meinem GitLab CI-Build, der das maven:3.5.4-jdk-8Docker-Image verwendete.

Ändern Sie es, um maven:3.5.4-jdk-8-alpinedas Problem zu beheben.

Ich folgte diesem Link https://maven.apache.org/surefire/maven-surefire-plugin/examples/class-loading.html und fügte das folgende Plugin in pom.xml hinzu und es funktionierte,

<project>
  [...]
  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-surefire-plugin</artifactId>
        <version>2.22.1</version>
        <configuration>
          <useSystemClassLoader>false</useSystemClassLoader>
        </configuration>
      </plugin>
    </plugins>
  </build>
  [...]
</project>

Bei Verwendung von GitLab CI / CD mit 3.6.0-jdk-8Image hat nur die unten stehende Eigenschaft geholfen (ohne Änderungen vorzunehmen pom.xml).

-Dsurefire.useSystemClassLoader=false

Informationen zu Antworten auf Docker Maven: 3.5.x-jdk-8 in GitLab CI finden Sie in diesem GitHub-Problem .

Es scheint, dass ein 3.5.4-jdk-8Image zu einem Upgrade auf eine kleinere Java-Version geführt hat, was sich irgendwie auf den Gabelmechanismus von Surefire auswirkt.

Das 3.5.3-jdk-8Zurücksetzen auf das Image hat dies für mich auf meinem GitLab CI-Server behoben, der Java 1.8-Code mit Surefire 2.20.1 erstellt.

Der obige Vorschlag, die Eigenschaft "-Djdk.net.URLClassPath.disableClassPathURLCheck = true" festzulegen, hat bei mir NICHT funktioniert, aber das Festlegen der folgenden Elemente funktioniert in Ordnung:

-DforkCount=0

Für Ubuntu: Installieren Sie die neueste Version, es hat diesen Fehler behoben

sudo apt-get update ; sudo apt-get dist-upgrade -y

Installieren Sie die letzte funktionierende Version (ohne Sicherheitspatches) ohne den Fehler.

sudo apt-get install openjdk-8-jdk-headless=8u181-b13-1 openjdk-8-jdk=8u181-b13-1  openjdk-8-jre=8u181-b13-1  openjdk-8-jre-headless=8u181-b13-1 openjdk-8-source=8u181-b13-1

Wenn Sie diese Version verpasst haben, verwenden Sie die vorherige Version:

sudo apt-get install openjdk-8-jdk-headless=8u162-b12-1 openjdk-8-jdk=8u162-b12-1  openjdk-8-jre=8u162-b12-1  openjdk-8-jre-headless=8u162-b12-1 openjdk-8-source=8u162-b12-1

Verwenden Sie dann entweder Pinning oder achten Sie darauf, dass Sie die defekte Version nicht installieren.

Die Verwendung -Djdk.net.URLClassPath.disableClassPathURLCheck=truefunktionierte bei mir nicht, wo immer ich diese Konfiguration vorgenommen hatte. Irgendwo in meinen Integrationstests wurde es immer ohne die alte Java-Version beendet.

Wie von Erich erwähnt, ist es ein Fehler im Debian-Paket, zu streng 911925 zu sein und das Surefire-Plugin nicht gemäß den neuen Regeln SUREFIRE-1588 zu handeln .

Ich habe der Junit-Jupiter-Engine eine Abhängigkeit hinzugefügt, und es hat funktioniert.

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-surefire-plugin</artifactId>
    <version>2.22.1</version>
    <dependencies>
        <dependency>
            <groupId>org.junit.jupiter</groupId>
            <artifactId>junit-jupiter-engine</artifactId>
            <version>5.4.0</version>
        </dependency>
    </dependencies>
</plugin>

Ich habe kürzlich einen Maven-Job bei Jenkins eingerichtet und bin in das gleiche Problem geraten. Ich nahm den Vorschlag an, die JAVA env-Variable zu ändern und das gelöste Problem zu bestätigen. So habe ich getestet.

Wird "jenkins" Benutzer und ändert den Ordner in den Projektnamen des Arbeitsbereichs, den Sie für den Job eingerichtet haben.

 $ _JAVA_OPTIONS=-Djdk.net.URLClassPath.disableClassPathURLCheck=true mvn clean install -U

 $ lsb_release -rd
 Description:   Ubuntu 16.04.5 LTS
 Release:   16.04

 $ mvn -v
 Apache Maven 3.3.9
 Maven home: /usr/share/maven
 Java version: 1.8.0_181, vendor: Oracle Corporation
 Java home: /usr/lib/jvm/java-8-openjdk-amd64/jre
 Default locale: en_US, platform encoding: UTF-8
 OS name: "linux", version: "4.4.0-131-generic", arch: "amd64", family: "unix"

Durch Hinzufügen zum Maven-Surefire-Plugin habe ich das Problem behoben:

    <plugin>    
        <groupId>org.apache.maven.plugins</groupId> 
        <artifactId>maven-surefire-plugin</artifactId>  
        <configuration>
            <forkCount>0</forkCount>
        </configuration>
    </plugin>

Grundsätzlich liegt eine Inkompatibilität zwischen der JDK-Version und der Maven-Surefire-Plugin-Version vor. In meinem Fall funktioniert JDK 11.0.5 nicht mit Surefire 3.0.0-M4. Ich musste auf 3.0.0-M3 umsteigen und es hat funktioniert. Wenn Sie forkCount auf 0 setzen, wird das Problem nicht behoben, da der Jacoco-Bericht beschädigt wird.

Ich habe das JDK deinstalliert, das in den Repositorys enthalten ist:

$ sudo apt purge openjdk-8-jdk

$ sudo apt autoremove

Dann habe ich die JAVA_HOMEUmgebungsvariable gelöscht . Meins wurde in meinem .bashrc eingestellt.

Dann habe ich es über SDKMAN neu installiert:

$ sdk install java 8.0.181-zulu

Von ihrer Website :

SDKMAN! ist ein Tool zum Verwalten paralleler Versionen mehrerer Software Development Kits auf den meisten Unix-basierten Systemen. Es bietet eine praktische Befehlszeilenschnittstelle (Command Line Interface, CLI) und eine API zum Installieren, Wechseln, Entfernen und Auflisten von Kandidaten.

Verwenden Sie Folgendes, um andere zu installierende Versionen des JDK anzuzeigen:

$ sdk list java

Ich hatte das gleiche Problem mit gitlab ci und wechselte das Maven-Image von maven:3-jdk-8 in maven:3.6.0-jdk-8-alpinescheint das Problem zu beheben. Übrigens habe ich auch mit getestet, maven:3.6.0-jdk-8aber es hat auch nicht funktioniert.

Es ist immer noch ein Problem surefire - v2.22.2mit maven:3.6-jdk-8-alpine. Um das Problem zu beheben, fügen Sie den folgenden Code hinzu pom.xml(als Maven-Plugin).

...
<plugin>    
    <groupId>org.apache.maven.plugins</groupId> 
    <artifactId>maven-surefire-plugin</artifactId>  
    <configuration>
        <forkCount>0</forkCount>
    </configuration>
</plugin>
...

Wenn Sie wie ich Probleme in Ihrer Pipeline haben (für mich ist es in GitLab, aber was auch immer) und wenn Sie ein Maven JDK 8 Docker-Image verwenden.

Sie können ersetzen

image: maven:3.5.4-jdk-8

bis zum letzten funktionierenden Build

image: maven@sha256:b37da91062d450f3c11c619187f0207bbb497fc89d265a46bbc6dc5f17c02a2b