web-dev-qa-db-fra.com

Maven sûr de ne pas pouvoir trouver la classe ForkedBooter

Venant récemment d'un nouveau projet, j'essaye de compiler notre code source. Tout a bien fonctionné hier, mais aujourd'hui, c'est une autre histoire.

Chaque fois que j'exécute mvn clean install sur un module, une fois les tests terminés, une erreur est générée:

[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

et plus tard:

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

J'utilise Debian 9 (Stretch) 64 bits avec OpenJDK 1.8.0_181, Maven 3.5.4, derrière le proxy de ma société que j'ai configuré dans mon ~/.m2/settings.xml.

Chose étrange, la dernière version de Surefire est la 2.22.1 si je me souviens bien. J'ai essayé de spécifier la version du plugin, mais elle n'est pas mise à jour, sinon il n'y a pas de spécification de version de plugin dans aucun POM (parent, grand-parent ou celui-ci).

J'ai réussi à forcer Maven à changer la version de Surefire au plus tard, mais maintenant c'est encore pire:

[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)
javamavenmaven-surefire-plugin
186
Sylordis

Pour résoudre ce problème (en 2018), mettez à jour votre openjdk vers la dernière version, au moins 8u191-b12. Si ce problème réapparaissait en 2020, il est probable que le comportement par défaut d'Openjdk a été modifié. devra ensuite mettre à jour le plugin Maven Surefire.

C’était un maintenant corrigé _ {un bogue dans le paquet openjdk-8 _ (le comportement s'écarte de manière significative en amont sans nécessité; il manque le correctif en amont pour revenir à la désactivation du contrôle de sécurité) que vous venez de mettre à niveau. Mais c’est aussi un bug dans le plugin surefire, SUREFIRE-1588, prétendument corrigé dans surefire 3.0.0-M1 : il utilise apparemment des chemins absolus à un endroit où Java le fera à l’avenir n'autorise que les noms de chemins relatifs (et Debian a déjà activé le comportement futur).

La version du package 8u181-b13-2 indique:

  • Appliquez les correctifs de la mise à jour de sécurité 8u191-b12.

Notez que 191-b12! = 181-b13. Les correctifs de sécurité 191-b12 venaient juste de sortir il y a quelques jours et apparemment, les responsables de la maintenance souhaitaient vous les envoyer rapidement. Une mise à jour complète vers 191-b12 nécessitera probablement des tests supplémentaires (enfin, ce téléchargement devrait apparemment avoir lieu).

Il y avait eu plusieurs solutions:

  1. Vous pouvez installer le paquet précédent à partir de snapshots.d.o à la place. Après la rétrogradation, vous pouvez interdire la version endommagée (si vous utilisez aptitude et non apt) en utilisant Sudo aptitude forbid-version openjdk-8-jre-headless. Pour "apt" habituel, je n'ai pas vu de mécanisme d'interdiction similaire, vous aurez donc probablement besoin d'utiliser apt pour épingler pour empêcher la réinstallation de cette mise à jour (ou vous continuez simplement à rétrograder à nouveau, j'espère que ce problème sera bientôt résolu).
  2. Selon le suivi des bogues, définir la propriété -Djdk.net.URLClassPath.disableClassPathURLCheck=true avec l’une des méthodes habituelles (par exemple, Java_FLAGS) devrait également aider. Mais je n'ai pas vérifié cela moi-même. Vous pouvez apparemment même ajouter la solution de contournement à ~/.m2/settings.xml pour l'activer facilement pour toutes vos versions de Maven.

Comme vous pouvez le constater, le suivi des bogues fonctionne, le problème a été réduit, un package corrigé est disponible et une nouvelle version du plugin surefire sera bientôt disponible!

228
Erich Schubert

J'ai trouvé cette solution de contournement et corrige mes tests: configurez le maven-surefire-plugin pour ne pas utiliser le chargeur de classes du système.

47
user3090935

Définissez useSystemClassloader sur false:

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

Si vous n'héritez pas d'un parent dont la version est définie pour vous (telle que le démarreur Spring Boot), vous devez également le définir.

44
Markoorn

J'ai une autre solution de contournement. Définissez la variable d'environnement _Java_OPTIONS. Je l'ai utilisé pour nos agents de génération TeamCity et maintenant nos versions fonctionnent correctement.

_Java_OPTIONS=-Djdk.net.URLClassPath.disableClassPathURLCheck=true
36
Michael

J'ai posté une variante plus ciblée de l'une des solutions de contournement ci-dessus dans JIRA . Ajouter à ~/.m2/settings.xml:

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

J'ai eu ce problème dans ma version de GitLab CI, qui utilisait maven:3.5.4-jdk-8 Docker image.

Le changer en maven:3.5.4-jdk-8-Alpine a résolu le problème.

8
brunobastosg

J'ai suivi ce lien https://maven.Apache.org/surefire/maven-surefire-plugin/examples/class-loading.html et ajouté le plugin ci-dessous dans pom.xml et cela a fonctionné

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

Pour Ubuntu: Installez la dernière version, ce bug a été corrigé

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

Installez la dernière version de travail (sans correctifs de sécurité) sans le bogue.

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

Si vous avez manqué cette version, utilisez la version précédente:

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

Ensuite, utilisez pinning ou veillez à ne pas installer la version endommagée.

Utiliser -Djdk.net.URLClassPath.disableClassPathURLCheck=true ne fonctionnait pas pour moi où que je sois installé avec cette configuration. Quelque part dans mes tests d'intégration, il s'est toujours terminé sans l'ancienne version Java.

Comme mentionné par Erich c'est un bogue du paquet Debian trop strict 911925 et le plug-in Surefire n'agissant pas conformément aux nouvelles règles SUREFIRE-1588 .

4
flob

La suggestion ci-dessus visant à définir la propriété "-Djdk.net.URLClassPath.disableClassPathURLCheck = true" n'a pas fonctionné pour moi, mais le paramétrage suivant fonctionne correctement:

-DforkCount=0
4
farid g.

Lorsque vous utilisez GitLab CI/CD avec 3.6.0-jdk-8 image, seule la propriété ci-dessous vous aide (sans modifier pom.xml).

-Dsurefire.useSystemClassLoader=false
4
Grzes

Pour ceux qui recherchent une réponse liée à Docker Maven: 3.5.x-jdk-8 sur GitLab CI, voir ce problème GitHub .

Il semble qu'une image 3.5.4-jdk-8 ait entraîné une mise à niveau vers une version Java mineure, qui affecte en quelque sorte le mécanisme de forking de Surefire.

Revenir à 3.5.3-jdk-8 image corrige cela pour moi sur mon serveur GitLab CI créant le code Java 1.8 avec Surefire 2.20.1.

4
Simon Diemert

J'ai récemment installé Maven Job sur Jenkins et je me suis retrouvé coincé dans le même problème. J'ai pris la suggestion de modifier la variable Java env et confirmer le problème résolu. Voici comment j'ai testé.

Devient l'utilisateur "jenkins" et change le dossier en nom de projet d'espace de travail que vous avez configuré pour le travail.

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

J'ai ajouté la dépendance à junit-jupiter-engine, et cela a fonctionné.

<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>
0
Adi Baboianu

J'ai désinstallé le JDK inclus dans les référentiels:

$ Sudo apt purge openjdk-8-jdk

$ Sudo apt autoremove

Ensuite, j'ai supprimé la variable d'environnement Java_HOME. Le mien était placé dans mon .bashrc.

Puis je l'ai réinstallé via SDKMAN:

$ sdk install Java 8.0.181-zulu

De leur site :

SDKMAN! est un outil de gestion de versions parallèles de plusieurs kits de développement logiciel sur la plupart des systèmes Unix. Il fournit une interface de ligne de commande (CLI) et une API pratiques pour l'installation, la commutation, la suppression et la liste des candidats.

Pour voir les autres versions du JDK à installer, utilisez:

$ sdk list Java
0
jumpnett

Je faisais face au même problème avec gitlab ci, changer l'image maven de maven:3-jdk-8 à maven:3.6.0-jdk-8-Alpine semble résoudre le problème. Btw j'ai également testé avec maven:3.6.0-jdk-8 mais cela n'a pas fonctionné non plus.

0
mndeveci