Pewny ogień Maven nie mógł znaleźć klasy ForkedBooter

Niedawno przyjeżdżam do nowego projektu, próbuję skompilować nasz kod źródłowy. Wczoraj wszystko działało dobrze, ale dzisiaj jest inna historia.

Za każdym razem, gdy uruchamiam mvn clean installmoduł, po przejściu do testów, pojawia się błąd:

[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

a później:

[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?

Używam 64-bitowego systemu Debian 9 (Stretch) z OpenJDK 1.8.0_181, Maven 3.5.4, pracując za moim firmowym serwerem proxy, który skonfigurowałem w swoim ~/.m2/settings.xml.

Dziwną rzeczą jest to, że najnowsza wersja Surefire to 2.22.1, jeśli dobrze pamiętam. Próbowałem określić wersję wtyczki, ale nie jest ona aktualizowana, w przeciwnym razie nie ma specyfikacji wersji wtyczki w żadnym POM (rodzicu, dziadku lub tym).

Udało mi się zmusić Maven do zmiany wersji Surefire na najnowszą, ale teraz jest jeszcze gorzej:

[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)

Aby to naprawić (w 2018 r.), Zaktualizuj openjdk do najnowszej wersji, co najmniej 8u191-b12. W przypadku ponownego pojawienia się tego problemu w 2020 r. Prawdopodobne jest, że domyślne zachowanie openjdk zostało zmienione, a następnie konieczna będzie aktualizacja wtyczki maven surefire.

To był już naprawiony błąd w pakiecie openjdk-8 (zachowanie odbiega znacznie od upstream bez potrzeby; brak poprawki upstream, aby powrócić do wyłączenia kontroli bezpieczeństwa), do której właśnie zaktualizowałeś. Ale jest też błąd w murowany wtyczki, murowany, 1588 , rzekomo ustalonego SureFire 3.0.0-M1 : to widocznie jest za pomocą ścieżek bezwzględnych w miejscu, gdzie Java będzie w przyszłości umożliwić tylko nazwy ścieżki względnej (i Debian aktywowany przyszłe zachowanie już).

Wersja pakietu 8u181-b13-2 stanowi:

• Zastosuj poprawki z aktualizacji zabezpieczeń 8u191-b12.

Zauważ, że 191-b12! = 181-b13. Poprawki bezpieczeństwa 191-b12 zostały wydane kilka dni temu i najwyraźniej opiekunowie chcieli szybko je dostarczyć. Całkowite uaktualnienie do wersji 191-b12 prawdopodobnie będzie wymagało dodatkowych testów (no cóż, więc najwyraźniej powinien mieć ten upload).

Było kilka problemów:

1. Zamiast tego możesz zainstalować poprzedni pakiet z snapshots.do . Po obniżeniu wersji możesz zabronić używania uszkodzonej wersji (jeśli używasz aptitude, ale nie aptużywasz) sudo aptitude forbid-version openjdk-8-jre-headless. W przypadku zwykłego „apt” nie widziałem podobnego mechanizmu zabraniającego, więc prawdopodobnie będziesz musiał użyć apt pin, aby zapobiec ponownej instalacji tego uaktualnienia (lub po prostu kontynuuj obniżanie, mam nadzieję, że zostanie to wkrótce rozwiązane).
2. Zgodnie ze śledzeniem błędów, ustawienie właściwości -Djdk.net.URLClassPath.disableClassPathURLCheck=trueza pomocą zwykłych metod (np. JAVA_FLAGS) Powinno również pomóc. Ale sam tego nie zweryfikowałem. Najwyraźniej możesz nawet dodać obejście, aby~/.m2/settings.xml włączyć je łatwo dla wszystkich swoich kompilacji Maven.

Jak widać, śledzenie błędów działa , problem został zawężony, dostępny jest poprawiony pakiet, a wkrótce pojawi się nowa wersja wtyczki surefire!

Ustaw useSystemClassloader na false:

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

Jeśli nie dziedziczysz po rodzicu, który ma dla Ciebie wersję (np. Spring Boot Starter), musisz to również zdefiniować.

Znalazłem to obejście i naprawiłem moje testy: skonfiguruj, aby maven-surefire-pluginnie korzystał z systemowego modułu ładującego.

Mam inne obejście. Ustaw zmienną środowiskową _JAVA_OPTIONS. Użyłem tego dla naszych agentów kompilacji TeamCity, a teraz nasze kompilacje działają poprawnie.

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

Opublikowałem bardziej ukierunkowany wariant jednego z powyższych obejść w JIRA . Dodaj do ~/.m2/settings.xml:

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

Miałem ten problem w mojej kompilacji GitLab CI, która używała maven:3.5.4-jdk-8obrazu Docker.

Zmiana w celu maven:3.5.4-jdk-8-alpinerozwiązania problemu.

Śledziłem ten link https://maven.apache.org/surefire/maven-surefire-plugin/examples/class-loading.html i dodałem poniższą wtyczkę do pom.xml i działała,

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

W przypadku korzystania z GitLab CI / CD z 3.6.0-jdk-8obrazem pomogła tylko poniższa właściwość (bez modyfikacji pom.xml).

-Dsurefire.useSystemClassLoader=false

Dla tych, którzy szukają odpowiedzi związanej z Docker Maven: 3.5.x-jdk-8 w GitLab CI, zobacz ten problem GitHub .

Wygląda na to 3.5.4-jdk-8 obraz spowodował aktualizację do mniejszej wersji Java, co w jakiś sposób wpływa na mechanizm rozwidlania Surefire.

Cofanie do 3.5.3-jdk-8obrazu naprawiło to na moim serwerze GitLab CI budującym kod Java 1.8 z Surefire 2.20.1.

Powyższa sugestia, aby ustawić właściwość „-Djdk.net.URLClassPath.disableClassPathURLCheck = true” NIE działała dla mnie, ale ustawienie następujących opcji działa OK:

-DforkCount=0

W przypadku Ubuntu: zainstaluj najnowszą wersję, naprawiono ten błąd

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

Zainstaluj ostatnią działającą wersję (bez poprawek bezpieczeństwa) bez błędu.

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

Jeśli przegapiłeś tę wersję, użyj wcześniejszej wersji:

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

Następnie użyj przypięcia lub uważaj, aby nie zainstalować uszkodzonej wersji.

Używanie -Djdk.net.URLClassPath.disableClassPathURLCheck=truenie działało dla mnie, gdziekolwiek ustawiłem tę konfigurację. Gdzieś w moich testach integracyjnych zawsze kończyło się bez starej wersji Java.

Jak wspomniał Erich , błąd w pakiecie Debian jest zbyt ścisły 911925, a wtyczka Surefire nie działa zgodnie z nowymi zasadami SUREFIRE-1588 .

Dodałem zależność do silnika junit-jupiter i zadziałało.

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

Niedawno skonfigurowałem pracę w Jenkins i utknąłem w tym samym problemie. Przyjąłem sugestię modyfikacji zmiennej env JAVA i potwierdziłem, że problem został rozwiązany. Tak testowałem.

Zostaje użytkownikiem „jenkins” i zmienia folder na nazwę projektu obszaru roboczego skonfigurowanego dla zadania.

 $ _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"

Dodając to do wtyczki maven-surefire, rozwiązałem problem:

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

Zasadniczo jest niezgodność między wersją JDK a wersją wtyczki maven-surefire, w moim przypadku JDK 11.0.5 nie działa z surefire 3.0.0-M4, musiałem przełączyć się na 3.0.0-M3 i działało. ustawienie forkCount na 0 nie rozwiązuje problemu, ponieważ psuje raport Jacoco.

Odinstalowałem pakiet JDK znajdujący się w repozytoriach:

$ sudo apt purge openjdk-8-jdk

$ sudo apt autoremove

Następnie usunąłem JAVA_HOMEzmienną środowiskową. Mój został ustawiony w moim .bashrc.

Następnie przeinstalowałem go za pomocą SDKMAN:

$ sdk install java 8.0.181-zulu

Z ich strony :

SDKMAN! to narzędzie do zarządzania równoległymi wersjami wielu zestawów programistycznych w większości systemów opartych na Uniksie. Zapewnia wygodny interfejs wiersza poleceń (CLI) i interfejs API do instalowania, przełączania, usuwania i wystawiania kandydatów.

Aby zobaczyć inne wersje JDK do zainstalowania, użyj:

$ sdk list java

Miałem do czynienia z tym samym problemem z gitlab ci, zmiana obrazu maven z maven:3-jdk-8na maven:3.6.0-jdk-8-alpinewydaje się naprawiać problem. Btw też testowałem, maven:3.6.0-jdk-8ale to też nie działało.

Jest jeszcze problem dla surefire - v2.22.2o maven:3.6-jdk-8-alpine. Aby rozwiązać problem, dodaj poniższy kod do pom.xml(jako wtyczki maven)

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

Jeśli tak jak ja, masz problemy w przygotowaniu (dla mnie jest to GitLab, ale cokolwiek) i jeśli używasz obrazu Daven MD JDK 8.

Możesz wymienić

image: maven:3.5.4-jdk-8

według ostatniej działającej wersji

image: maven@sha256:b37da91062d450f3c11c619187f0207bbb497fc89d265a46bbc6dc5f17c02a2b