Maven todsicher konnte die ForkedBooter-Klasse nicht finden

217

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)
Sylordis
quelle
1
Ich habe diesen Fehler in Clircle-CI. Surefire Forks und Forked VM druckt die folgende Meldung und wird beendet: "Fehler: Hauptklasse org.apache.maven.surefire.booter.ForkedBooter konnte nicht gefunden oder geladen werden". Die Massage ist in Ziel / todsicheren Berichten / *. Dumpstream. Wenn Sie maven mit -X ausführen, wird die Befehlszeile gedruckt. Sie können es versuchen und sehen, wie der VM diese Nachricht druckt.
Bruno Coutinho
Meine Lösung bestand darin, keine Open-JDKS mehr zu verwenden. Ich kann mir diese Art von Unzuverlässigkeit in etwas so Grundlegendem nicht leisten.
Adrian M.
Verwenden Sie den dependencyManagementAbschnitt von maven , um verschiedene Versionen von Plugins anzugeben
jogaco
Das Update auf jdk 11 auf Debian war eine todsichere Lösung für mich!
klares Licht

Antworten:

251

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!

Erich Schubert
quelle
@AdrianMadaras Ich habe bisher kein neues Update bekommen, nur die -2 Version. Es gab auch noch keine Ankündigung eines festen Uploads, aber es ist im Gange. Sie haben wahrscheinlich gerade ein Upgrade auf die bekannte problematische Version durchgeführt.
Erich Schubert
1
Ich habe gerade das gleiche Problem unter Ubuntu 18.04 mit OpenJDK 10.0.2. Das Umschalten von JAVA_HOME auf meine 'Java-9-Orakel'-Installation hat das Problem behoben.
RobAu
2
Hier ist das entsprechende Problem im Issue-Tracker für das todsichere Maven-Plugin: issue.apache.org/jira/browse/SUREFIRE-1588 (es ist immer noch ein Fehler im Canonical / Debian-Backport der relevanten OpenJDK-Änderungen).
Mirabilos
1
Umgehen 1. macht für mich keinen Sinn, da dies die Version ist, bei der das Problem auftritt. Das Überschreiben des Maven-Surefire-Plugins, um SystemClassLoader nicht zu verwenden, funktionierte ebenfalls nicht
Edwin Diaz-Mendez
1
Sie können auch versuchen, ein Upgrade auf todsicheres 3.0.0-M1 durchzuführen. Aber 2 bis 3 Meilenstein-Versionen können natürlich andere Dinge kaputt machen.
Erich Schubert
54

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.

Markoorn
quelle
Das Aktivieren des Systemklassenladeprogramms ist die schlechteste Vorgehensweise, da Sie die Tests im Plugin-Prozess ausführen. Die richtige Vorgehensweise besteht darin, die Version jedes Plugins zu aktualisieren. Maven 3.7.0 aktualisiert Versionen aller Plugins, die zum Standardlebenszyklus gehören. Die Feder sollte nicht an den alten Versionen festhalten und diese auch nicht überschreiben. Dies führt zu unnötigen Verantwortungskonflikten.
tibor17
52

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

user3090935
quelle
Laut dem Maven-Surefire-Plugin-Betreuer haben alle Problemumgehungen (dies, Einstellung forkCountauf 0 oder argLineglobale Einstellung ) Probleme und können nicht universell angewendet werden.
Mirabilos
Guter Fund. Aber bitte fügen Sie den eigentlichen Workaround-Text in Ihren Beitrag ein oder identifizieren Sie den Link zumindest eindeutig als Stackoverflow-Link. Dh der von @markoorn verwendete Ansatz ist hilfreicher.
Nealmcb
38

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
Michael
quelle
Eine bahnbrechende Änderung, die als Sicherheitsupdate gekennzeichnet ist, wird normalerweise nicht ohne Grund eingeführt, sodass jemand SO erklärt, wie sie deaktiviert werden soll ... sagen Sie einfach
berezovskyi
26

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>
Jesse Glick
quelle
Dies schlägt mit der folgenden Warnung fehl:[WARNING] Expected root element 'settings' but found 'profile' (position: START_TAG seen <profile>... @1:9) @ /home/nikolai/.m2/settings.xml, line 1, column 9
Nikolai
3
@ Nikolai Das obige Snippet muss beigefügt werden <settings><profiles>...</profiles></settings>.
qqx
13

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.

Brunobastosg
quelle
8

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>
Arunkumar Arjunan
quelle
8

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
Grzes
quelle
Dies ist wieder eine schlechte Praxis. Das Richtige ist, die Version zu aktualisieren. Überprüfen Sie immer die Versionen in Maven Central .
tibor17
5

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.

Simon Diemert
quelle
5

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
farid g.
quelle
2
Dies hat zur Folge, dass keine neue VM zum Ausführen der Tests erstellt wird, sodass die Tests möglicherweise die Haupt-Build-VM beeinflussen können.
Paŭlo Ebermann
4

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 .

Flob
quelle
Warum sollte jemand vorschlagen, eine Version ohne Sicherheitspatches zu installieren?! Obwohl andere Vorschläge das Überspringen von Tests beinhalten, nicht wahr?
berezovskyi
1
Du musst nicht mehr :-) Es ist behoben. In der Zwischenzeit hatte ich viele Java-Projekte, an denen ich arbeiten musste, und meine Java-Laufzeit war nirgends neuem Code von außen ausgesetzt. Es gab also ein überwachbares Risiko, das für mich in Ordnung war. Es ist schließlich jedermanns eigene Entscheidung :-)
Flob
Eigentlich haben Sie Recht, ich habe festgestellt, dass JDK-Entwickler auf diese standardmäßig festgelegte Requisite zurückgegangen sind: hg.openjdk.java.net/jdk/jdk/rev/f54dcfc5a5f8 ; Aber ein Upgrade der Hauptversion auf todsicher scheint mir eigentlich nicht die beste Lösung zu sein.
berezovskyi
1
Absolut! Aber die Änderungen, die sie vornehmen mussten, sind in der gesamten Codebasis und sehr invasiv. Eine geringfügige Versionsänderung für dieses Update wäre also keine Option in todsicheren Situationen.
Flob
1
Und leider wird 2.x eingestellt und wir müssen früher als später einen Wechsel vornehmen: issue.apache.org/jira/browse/…
berezovskyi
2

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>
Adi Baboianu
quelle
Welche schwarze Magie macht dieses Jupiter-Plugin? Das hat bei mir funktioniert! Upvote! :-)
Hinotori
1

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"
Boonchu Ngampairoijpibul
quelle
1

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>
Ruben Romero
quelle
1

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.

apolo884
quelle
0

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
Jumpnett
quelle
0

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.

mndeveci
quelle
0

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>
...
KimchiMan
quelle
-1

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
amdev
quelle
1
Das Problem kommt vom neuesten jdk8 für debian. Meiner Meinung nach ist es besser, das Kernproblem zu "beheben", als zu versuchen, es zu umgehen.
Sylordis
Der sha256 klingt knifflig und hat Angst vor dir? Eigentlich sieht eine andere Antwort eher wie eine Problemumgehung aus. Deaktivieren Sie eine Funktion von todsicher. Hier geht es nur darum, das letzte funktionierende Docker-Image zu verwenden, ohne Ihren Pom oder Ihre Pipeline zu ändern, die eine Problemumgehung darstellt.
Amdev