Maven surefire no pudo encontrar la clase ForkedBooter

218

Recientemente llegando a un nuevo proyecto, estoy tratando de compilar nuestro código fuente. Todo funcionó bien ayer, pero hoy es otra historia.

Cada vez que ejecuto mvn clean installun módulo, una vez que alcanzo las pruebas, se bloquea con un error:

[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

y luego:

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

Estoy ejecutando Debian 9 (Stretch) de 64 bits con OpenJDK 1.8.0_181, Maven 3.5.4, trabajando detrás del proxy de mi compañía que configuré en mi ~/.m2/settings.xml.

Una cosa extraña es que la última versión de Surefire es 2.22.1 si no recuerdo mal. Intenté especificar la versión del complemento, pero no se actualiza, de lo contrario no hay una especificación de versión del complemento en ningún POM (padre, abuelo o este).

Logré obligar a Maven a cambiar la versión Surefire a la última, pero ahora es aún peor:

[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)
java  maven  maven-surefire-plugin 
— Sylordis
fuente
1
Estoy teniendo este error en clircle-ci. Surefire bifurca y bifurca vm imprime el siguiente mensaje y sale: "Error: no se pudo encontrar o cargar la clase principal org.apache.maven.surefire.booter.ForkedBooter". El masaje está en target / surefire-reports / *. Dumpstream. Si ejecuta maven con -X, imprime la línea de comando, puede probarlo y ver el vm imprimiendo este mensaje.
— Bruno Coutinho
3
— jediz
mi solución fue dejar de usar open-jdks de cualquier versión. no puede permitirse este tipo de falta de fiabilidad en algo tan fundamental.
— Adrian M.
Utilizar Maven dependencyManagementsección para especificar diferentes versiones de plugins
— jogaco
¡La actualización a jdk 11 en Debian fue una solución segura para mí!
— claro

Respuestas:

251

Para solucionarlo (en 2018), actualice su openjdk a la última versión, al menos 8u191-b12. En caso de que este problema vuelva a aparecer en 2020, es probable que se haya cambiado el comportamiento predeterminado de openjdk, y luego deberá actualizar el complemento maven surefire.

Este era un error ahora corregido en el paquete openjdk-8 (el comportamiento se desvía significativamente del flujo ascendente sin necesidad; falta el parche ascendente para volver a deshabilitar un control de seguridad) que acaba de actualizar. Pero también es un error en el complemento surefire, SUREFIRE-1588 , supuestamente corregido en surefire 3.0.0-M1 : aparentemente está usando rutas absolutas en un lugar donde Java en el futuro solo permitirá nombres de ruta relativos (y Debian activó el comportamiento futuro ya).

La versión del paquete 8u181-b13-2 establece:

  • Aplique parches de la actualización de seguridad 8u191-b12.

Tenga en cuenta que 191-b12! = 181-b13. Los parches de seguridad 191-b12 salieron hace unos días, y aparentemente los encargados del mantenimiento querían enviárselos rápidamente. La actualización completa a 191-b12 probablemente necesitará pruebas adicionales (bueno, aparentemente debería tener esta carga).

Hubo varias soluciones:

  1. Puede instalar el paquete anterior desde snapshots.do en su lugar. Después de la degradación, puede prohibir el uso de la versión dañada (si está usando aptitude y no apt) sudo aptitude forbid-version openjdk-8-jre-headless. Para el "apt" normal, no vi un mecanismo de prohibición similar, por lo que es probable que necesite usar el anclaje de apt para evitar que se reinstale esta actualización (o simplemente continúe degradando nuevamente, espero que esto se resuelva pronto).
  2. Según el seguimiento de errores, también debería ser útil establecer la propiedad -Djdk.net.URLClassPath.disableClassPathURLCheck=truecon cualquiera de los métodos habituales (por ejemplo, JAVA_FLAGS) Pero no lo he verificado yo mismo. Aparentemente, incluso puede agregar la solución alternativa para~/.m2/settings.xml habilitarla para todas sus compilaciones de Maven fácilmente.

Como puede ver, el seguimiento de errores funciona , el problema se redujo, y hay un paquete fijo disponible y ¡pronto llegará una nueva versión del complemento seguro!

— Erich Schubert
fuente
@AdrianMadaras No recibí una nueva actualización hasta ahora, solo la versión -2. Tampoco hubo un anuncio de una carga fija todavía, pero está en marcha. Probablemente acaba de actualizar a la versión problemática conocida.
— Erich Schubert
1
Acabo de tener el mismo problema en Ubuntu 18.04, usando OpenJDK 10.0.2. El cambio de JAVA_HOME a mi instalación 'java-9-oracle' lo arregló.
— RobAu
2
Aquí está el problema correspondiente en el rastreador de problemas surefire-maven-plugin: issues.apache.org/jira/browse/SUREFIRE-1588 (sigue siendo un error en el backport Canonical / Debian de los cambios relevantes de OpenJDK).
— mirabilos
1
La solución 1. no tiene sentido para mí, ya que esa es la versión en la que estoy experimentando el problema. Anular el plugin maven-surefire-plugin para no usar SystemClassLoader tampoco funcionó
— Edwin Diaz-Mendez
1
También puede intentar actualizar a surefire 3.0.0-M1. Pero la versión de 2 a 3 hitos puede, por supuesto, romper otras cosas.
— Erich Schubert
54

Establezca useSystemClassloader en falso:

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

Si no está heredando de un padre que tiene una versión definida para usted (como el iniciador Spring Boot), deberá definir eso también.

— Markoorn
fuente
Habilitar el cargador de clases del sistema es la peor práctica debido a que está ejecutando las pruebas en el proceso de complemento. La práctica correcta es actualizar la versión de cada complemento. Maven 3.7.0 actualizará las versiones de todos los complementos que pertenecen al ciclo de vida predeterminado. Spring no debe adherirse a las versiones anteriores y tampoco debe anularlas. Esto causa conflictos innecesarios en las responsabilidades.
— tibor17
52

Encontré esta solución y solucioné mis pruebas: configure el maven-surefire-pluginpara no usar el cargador de clases del sistema.

— usuario3090935
fuente
Según el mantenedor de maven-surefire-plugin, todas las soluciones alternativas (esto, establecer forkCounta 0 o establecer argLineglobalmente) tienen problemas y no se pueden aplicar universalmente.
— mirabilos
Buen descubrimiento. Pero incluya el texto de la solución real en su publicación, o al menos identifique el enlace claramente como un enlace de stackoverflow. Es decir, el enfoque utilizado por @markoorn es más útil.
— nealmcb
38

Tengo otra solución alternativa. Establezca la variable de entorno _JAVA_OPTIONS. He usado esto para nuestros agentes de compilación de TeamCity y ahora nuestras compilaciones funcionan bien.

_JAVA_OPTIONS=-Djdk.net.URLClassPath.disableClassPathURLCheck=true
— Miguel
fuente
Por lo general, un cambio rotundo etiquetado como una solución de seguridad no se introduce sin ninguna razón, por lo que alguien le dice a SO cómo deshabilitarlo ... solo dice
— berezovskyi
26

Publiqué una variante más específica de una de las soluciones anteriores en JIRA . Añadir a ~/.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
fuente
Esto falla con la siguiente advertencia:[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 El fragmento anterior debe incluirse <settings><profiles>...</profiles></settings>.
— qqx
13

Tuve este problema en mi compilación GitLab CI, que estaba usando la maven:3.5.4-jdk-8imagen Docker.

Cambiándolo a maven:3.5.4-jdk-8-alpinesolucionado el problema.

— brunobastosg
fuente
8

Al usar GitLab CI / CD con 3.6.0-jdk-8imagen, solo la propiedad a continuación ayudó (sin modificar pom.xml).

-Dsurefire.useSystemClassLoader=false
— Grzes
fuente
Esto es nuevamente una mala práctica. El correcto es actualizar la versión. Siempre verifique las versiones en Maven Central .
— tibor17
5

Para aquellos que buscan una respuesta relacionada con Docker Maven: 3.5.x-jdk-8 en GitLab CI, vea este problema de GitHub .

Parece que una 3.5.4-jdk-8imagen resultó en una actualización a una versión menor de Java que de alguna manera afecta el mecanismo de bifurcación de Surefire.

Volver a la 3.5.3-jdk-8imagen me arregló esto en mi servidor GitLab CI construyendo código Java 1.8 con Surefire 2.20.1.

— Simon Diemert
fuente
5

La sugerencia anterior para establecer la propiedad "-Djdk.net.URLClassPath.disableClassPathURLCheck = true" NO funcionó para mí, pero configurar lo siguiente sí funciona bien:

-DforkCount=0
— farid g.
fuente
2
Esto tiene el efecto de no crear una nueva VM para ejecutar las pruebas, por lo que las pruebas pueden influir en la VM de compilación principal.
— Paŭlo Ebermann el
4

Para Ubuntu: instale la última versión, tiene este error corregido

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

Instale la última versión de trabajo (sin parches de seguridad) sin el error.

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 se perdió esa versión, use la versión anterior:

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

Luego use la fijación o tenga cuidado de que no instalará la versión dañada.

Usar -Djdk.net.URLClassPath.disableClassPathURLCheck=trueno funcionó para mí dondequiera que haya puesto esa configuración. En algún lugar de mis pruebas de integración siempre salió sin la versión antigua de Java.

Como mencionó Erich , es un error en el paquete Debian que es demasiado estricto 911925 y el plugin Surefire no actúa de acuerdo con las nuevas reglas SUREFIRE-1588 .

— flob
fuente
¿Por qué alguien sugeriría instalar una versión sin parches de seguridad? Aunque otras sugerencias incluyen saltar pruebas, ¿eh?
— berezovskyi
1
Ya no es necesario :-) Está solucionado. Pero, mientras tanto, tenía muchos proyectos de Java en los que tenía que trabajar y mi tiempo de ejecución de Java no estaba expuesto a ningún código nuevo externo. Así que había un riesgo supervisado que estaba bien para mí. Después de todo, es decisión de todos :-)
— flob
En realidad tiene razón, descubrí que los desarrolladores de JDK caminaron de regreso en ese conjunto de accesorios por defecto: hg.openjdk.java.net/jdk/jdk/rev/f54dcfc5a5f8 ; pero la actualización de la versión principal a Surefire no me parece la mejor solución, en realidad.
— berezovskyi
1
¡Absolutamente! Pero los cambios que tuvieron que hacer son en toda la base de código y muy invasivos. Por lo tanto, un cambio de versión menor para esta solución no sería una opción segura.
— flob
1
Y desafortunadamente, 2.x se descontinúa y tendremos que hacer un cambio más temprano que tarde: issues.apache.org/jira/browse/…
— berezovskyi
2

Agregué dependencia a junit-jupiter-engine, y funcionó.

<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
fuente
¿Qué magia negra hace este plugin de Júpiter? ¡Esto funcionó para mí! ¡Votación a favor! :-)
— Hinotori
1

Recientemente configuré el trabajo de Maven en Jenkins y me quedé atrapado en el mismo problema. Tomé la sugerencia de modificar la variable env JAVA y confirmar el problema resuelto. Así es como lo probé.

Se convierte en usuario "jenkins" y cambia la carpeta al nombre del proyecto del espacio de trabajo que configuró para el trabajo.

 $ _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
fuente
1

Al agregar esto al complemento maven-surefire, resolví el problema:

    <plugin>    
        <groupId>org.apache.maven.plugins</groupId> 
        <artifactId>maven-surefire-plugin</artifactId>  
        <configuration>
            <forkCount>0</forkCount>
        </configuration>
    </plugin>
— Ruben Romero
fuente
1

Básicamente es una incompatibilidad entre la versión JDK y la versión del complemento maven-surefire, en mi caso, JDK 11.0.5 no funciona con surefire 3.0.0-M4, tuve que cambiar a 3.0.0-M3 y funcionó. establecer forkCount en 0 no soluciona el problema porque rompe el informe de Jacoco.

— apolo884
fuente
0

Desinstalé el JDK que viene en los repositorios:

$ sudo apt purge openjdk-8-jdk

$ sudo apt autoremove

Luego eliminé la JAVA_HOMEvariable de entorno. La mía se estableció en mi .bashrc.

Luego lo reinstalé a través de SDKMAN:

$ sdk install java 8.0.181-zulu

Desde su sitio :

SDKMAN! es una herramienta para administrar versiones paralelas de múltiples kits de desarrollo de software en la mayoría de los sistemas basados ​​en Unix. Proporciona una conveniente interfaz de línea de comando (CLI) y API para instalar, cambiar, eliminar y enumerar candidatos.

Para ver otras versiones del JDK para instalar, use:

$ sdk list java
— jumpnett
fuente
0

Estaba enfrentando el mismo problema con gitlab ci, cambiar la imagen de maven de maven:3-jdk-8a maven:3.6.0-jdk-8-alpineparece solucionar el problema. Por cierto, también probé maven:3.6.0-jdk-8pero tampoco funcionó.

— mndeveci
fuente
0

Todavía es un problema surefire - v2.22.2con maven:3.6-jdk-8-alpine. Para solucionar el problema, agregue el siguiente código a pom.xml(como complemento de Maven)

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

Si como yo tiene problemas en su cartera (para mí está en GitLab, pero lo que sea) y si está utilizando una imagen Docker de Maven JDK 8.

Usted puede reemplazar

image: maven:3.5.4-jdk-8

por la última compilación de trabajo

image: maven@sha256:b37da91062d450f3c11c619187f0207bbb497fc89d265a46bbc6dc5f17c02a2b
— amdev
fuente
1
El problema proviene del último jdk8 para debian. En mi opinión, es mejor "solucionar" el problema central que tratar de solucionarlo.
— Sylordis
El sha256 suena complicado y te da miedo? En realidad, otra respuesta se parece más a una solución alternativa, deshabilite alguna característica de Surefire, aquí se trata de usar la última imagen de Docker que funciona sin cambiar su pom o tubería de trabajo, que es una solución alternativa.
— amdev
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.