page org not mvn instalar home found forkedbooter could booter java maven maven-surefire-plugin

java - org - maven home page



Maven surefire no pudo encontrar la clase de ForkedBooter (17)

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

-Dsurefire.useSystemClassLoader=false

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

Cada vez que mvn clean install en un módulo, una vez que alcanza las pruebas, se produce 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 más tarde:

[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 empresa que configuré en mi ~/.m2/settings.xml .

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

Logré obligar a Maven a cambiar la versión de 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)


Desinstalé el JDK que viene en los repositorios:

$ sudo apt purge openjdk-8-jdk $ sudo apt autoremove

Luego borré la variable de entorno JAVA_HOME . El mío se puso en mi .bashrc.

Luego lo reinstalé a través de SDKMAN:

$ sdk install java 8.0.181-zulu

Desde su site :

SDKMAN! es una herramienta para administrar versiones paralelas de varios Kits de desarrollo de software en la mayoría de los sistemas basados ​​en Unix. Proporciona una interfaz de línea de comandos (CLI) y una API convenientes para instalar, cambiar, eliminar y listar candidatos.

Para ver otras versiones del JDK para instalar, use:

$ sdk list java


Encontré esta solución y arreglé mis pruebas: configure el maven-surefire-plugin no use el cargador de clases del sistema.


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


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 arrancador Spring Boot), también deberá definirla.


Estoy acostumbrado a esto como una solución para detener la compilación y ejecución de archivos de prueba:

-Dmaven.test.skip=true with maven


He agregado la 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>


La sugerencia anterior para establecer la propiedad "-Djdk.net.URLClassPath.disableClassPathURLCheck = true" NO me funcionó, pero la configuración de lo siguiente funciona bien:

-DforkCount=0


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

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 te perdiste esa versión, usa la versión anterior a eso:

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, utilice la pinning o tenga cuidado de no instalar la versión rota.

El uso de -Djdk.net.URLClassPath.disableClassPathURLCheck=true no funcionó para mí dondequiera que había puesto esa configuración. En algún lugar de mis pruebas de integración siempre salió sin la versión anterior de Java.

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


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

Parece que una imagen 3.5.4-jdk-8 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 imagen 3.5.3-jdk-8 solucioné en mi servidor GitLab CI que construye el código Java 1.8 con Surefire 2.20.1.


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>


Recientemente instalé un trabajo experto 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 he probado.

Se convierte en usuario "jenkins" y cambia la carpeta al nombre del proyecto del área de trabajo que configura 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"


Seguí este enlace https://maven.apache.org/surefire/maven-surefire-plugin/examples/class-loading.html y agregué el siguiente complemento en pom.xml y funcionó.

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


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

Puede reemplazar

image: maven:3.5.4-jdk-8

por la última estructura de trabajo

image: maven@sha256:b37da91062d450f3c11c619187f0207bbb497fc89d265a46bbc6dc5f17c02a2b


Tengo otra solución. Establecer 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


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

Cambiándolo a maven:3.5.4-jdk-8-alpine solucionó el problema.


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 entonces deberá actualizar el complemento maven surefire.

Este fue un error ahora corregido en el paquete openjdk-8 (el comportamiento se desvía del flujo ascendente significativamente sin necesidad, faltando el parche ascendente para volver a desactivar la comprobación de seguridad) al 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 rutas relativas (y Debian activó la comportamiento futuro ya).

El paquete versión 8u181-b13-2 establece:

  • Aplicar parches de 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 mantenedores querían que te los enviaran rápidamente. Es probable que la actualización completa a 191-b12 necesite pruebas adicionales (bueno, por lo que debería tener esta carga, al parecer).

Ha habido varias soluciones

  1. Puede instalar el paquete anterior de snapshots.do en su lugar. Después de la degradación, puede prohibir la versión rota (si está utilizando aptitude y no apt ) usando sudo aptitude forbid-version openjdk-8-jre-headless . Para "apt" regular, no vi un mecanismo de prohibición similar, por lo que es probable que necesite usar apt pinning para evitar que se reinstale esta actualización (o simplemente continúa con la degradación nuevamente, espero que esto se resuelva pronto).
  2. De acuerdo con el seguimiento de errores, la configuración de la propiedad -Djdk.net.URLClassPath.disableClassPathURLCheck=true con cualquiera de los métodos habituales (por ejemplo, JAVA_FLAGS ) también debería ayudar. Pero no lo he comprobado yo mismo. Aparentemente, incluso puede agregar la solución a ~/.m2/settings.xml para habilitarlo para todas sus construcciones de Maven fácilmente.

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