Maven surefire no pudo encontrar la clase ForkedBooter

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)

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!

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.

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

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

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>

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.

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>

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

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.

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

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 .

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>

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"

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>

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.

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

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

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

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