Maven surefire não conseguiu encontrar a classe ForkedBooter

Recentemente, chegando a um novo projeto, estou tentando compilar nosso código-fonte. Tudo funcionou bem ontem, mas hoje é outra história.

Toda vez que estou executando mvn clean installem um módulo, uma vez atingido os testes, ocorre um erro:

[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

e depois:

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

Estou executando o Debian 9 (Stretch) de 64 bits com o OpenJDK 1.8.0_181, Maven 3.5.4, trabalhando por trás do proxy da minha empresa que eu configurei no meu ~/.m2/settings.xml.

Uma coisa estranha é que a versão mais recente do Surefire é a 2.22.1, se bem me lembro. Tentei especificar a versão do plug-in, mas ela não é atualizada; caso contrário, não há especificação de versão do plug-in em nenhum POM (pai, pai ou avô).

Consegui forçar o Maven a mudar a versão do Surefire para a mais recente, mas agora é ainda pior:

[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 corrigi-lo (em 2018), atualize seu openjdk para a versão mais recente, pelo menos 8u191-b12. Caso esse problema reapareça em 2020, é provável que o comportamento padrão do openjdk tenha sido alterado e você precisará atualizar o plugin maven surefire.

Esse era um bug agora corrigido no pacote openjdk-8 (o comportamento se desvia significativamente do upstream sem necessidade; falta do patch upstream para voltar a desativar a verificação de segurança) para a qual você acabou de atualizar. Mas também é um bug no plugin surefire, SUREFIRE-1588 , supostamente corrigido no surefire 3.0.0-M1 : aparentemente ele está usando caminhos absolutos em um local onde o Java no futuro permitirá apenas nomes de caminhos relativos (e o Debian ativou o comportamento futuro).

A versão do pacote 8u181-b13-2 declara:

• Aplique correções da atualização de segurança 8u191-b12.

Observe que 191-b12! = 181-b13. Os patches de segurança 191-b12 foram lançados há alguns dias e, aparentemente, os mantenedores queriam levá-los rapidamente. A atualização completa para o 191-b12 provavelmente precisará de testes adicionais (bem, portanto, deve ter esse upload, aparentemente).

Houve várias soluções alternativas:

1. Você pode instalar o pacote anterior a partir de snapshots.do . Após o downgrade, você pode proibir a versão quebrada (se você estiver usando o aptitude e não apt) usando sudo aptitude forbid-version openjdk-8-jre-headless. Para o "apt" normal, eu não via um mecanismo de proibição semelhante; portanto, você provavelmente precisaria usar a fixação do apt para impedir a reinstalação desta atualização (ou continue fazendo o downgrade novamente, espero que isso seja resolvido em breve).
2. De acordo com o rastreamento de erros, definir a propriedade -Djdk.net.URLClassPath.disableClassPathURLCheck=truecom qualquer um dos métodos usuais (por exemplo, JAVA_FLAGS) também deve ajudar. Mas eu não verifiquei isso pessoalmente. Aparentemente, você pode adicionar a solução alternativa para~/.m2/settings.xml habilitá-la para todas as suas compilações do Maven com facilidade.

Como você pode ver, o rastreamento de bugs funciona , o problema foi reduzido e um pacote fixo está disponível e uma nova versão do plugin surefire estará disponível em breve!

Defina useSystemClassloader como false:

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

Se você não estiver herdando de um pai com uma versão definida para você (como o iniciador do Spring Boot), será necessário definir isso também.

Encontrei esta solução alternativa e corrigi meus testes: configure o maven-surefire-pluginpara não usar o carregador de classe do sistema.

Eu tenho outra solução alternativa. Defina a variável de ambiente _JAVA_OPTIONS. Eu usei isso para nossos agentes de compilação TeamCity e agora nossas compilações funcionam bem.

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

Publiquei uma variante mais direcionada de uma das soluções alternativas acima no JIRA . Adicionar a ~/.m2/settings.xml:

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

Eu tive esse problema na minha compilação do GitLab CI, que estava usando a maven:3.5.4-jdk-8imagem do Docker.

Alterá-lo para maven:3.5.4-jdk-8-alpinecorrigir o problema.

Segui este link https://maven.apache.org/surefire/maven-surefire-plugin/examples/class-loading.html e adicionei o plug-in abaixo no pom.xml e ele funcionou,

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

Ao usar o GitLab CI / CD com 3.6.0-jdk-8imagem, apenas a propriedade abaixo ajudou (sem modificar pom.xml).

-Dsurefire.useSystemClassLoader=false

Para aqueles que procuram uma resposta relacionada ao Docker Maven: 3.5.x-jdk-8 no IC do GitLab, consulte este problema do GitHub .

Parece que uma 3.5.4-jdk-8imagem resultou na atualização para uma versão Java menor que de alguma forma afeta o mecanismo de bifurcação do Surefire.

A 3.5.3-jdk-8reversão da imagem corrigiu isso para mim no meu servidor GitLab CI que criava o código Java 1.8 com o Surefire 2.20.1.

A sugestão acima para definir a propriedade "-Djdk.net.URLClassPath.disableClassPathURLCheck = true" NÃO funcionou para mim, mas a configuração a seguir funciona OK:

-DforkCount=0

Para Ubuntu: instale a versão mais recente, este bug foi corrigido

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

Instale a última versão de trabalho (sem patches de segurança) sem o bug.

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

Se você perdeu essa versão, use a versão antes disso:

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

Em seguida, use pinagem ou cuidado para não instalar a versão quebrada.

Usar -Djdk.net.URLClassPath.disableClassPathURLCheck=truenão funcionou para mim onde quer que eu tivesse colocado essa configuração. Em algum lugar dos meus testes de integração, ele sempre saía sem a versão antiga do Java.

Como mencionado por Erich , é um bug no pacote Debian ser muito rigoroso 911925 e o plug-in Surefire não agir de acordo com as novas regras SUREFIRE-1588 .

Eu adicionei dependência ao junit-jupiter-engine, e funcionou.

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

Recentemente, configurei o trabalho de maven no Jenkins e fiquei preso ao mesmo problema. Aceitei a sugestão para modificar a variável env JAVA e confirme o problema resolvido. Foi assim que eu testei.

Torna-se usuário "jenkins" e altera a pasta para o nome do projeto da área de trabalho que você configurou para o trabalho.

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

Adicionando isso ao maven-surefire-plugin, resolvi o problema:

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

Basicamente, há uma incompatibilidade entre a versão JDK e a versão do plug-in maven-surefire. No meu caso, o JDK 11.0.5 não funciona com o surefire 3.0.0-M4, tive que mudar para 3.0.0-M3 e funcionou. definir forkCount como 0 não corrige o problema porque quebra o relatório Jacoco.

Eu desinstalei o JDK que vem nos repositórios:

$ sudo apt purge openjdk-8-jdk

$ sudo apt autoremove

Então eu apaguei a JAVA_HOMEvariável de ambiente. O meu foi colocado no meu .bashrc.

Então eu reinstalei-o através do SDKMAN:

$ sdk install java 8.0.181-zulu

Do site deles :

SDKMAN! é uma ferramenta para gerenciar versões paralelas de vários kits de desenvolvimento de software na maioria dos sistemas baseados em Unix. Ele fornece uma interface de linha de comando (CLI) conveniente e API para instalar, alternar, remover e listar candidatos.

Para ver outras versões do JDK para instalar, use:

$ sdk list java

Eu estava enfrentando o mesmo problema com o gitlab ci, alterar a imagem do maven de maven:3-jdk-8para maven:3.6.0-jdk-8-alpineparece corrigir o problema. Btw eu também testei com maven:3.6.0-jdk-8mas não funcionou nem.

Ainda é um problema surefire - v2.22.2com maven:3.6-jdk-8-alpine. Para corrigir o problema, adicione o código abaixo a pom.xml(como plugin do maven)

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

Se como eu, você tem problemas em seu pipeline (para mim está no GitLab, mas tanto faz) e se você estiver usando uma imagem do Maven JDK 8 Docker.

Você pode substituir

image: maven:3.5.4-jdk-8

pela última compilação de trabalho

image: maven@sha256:b37da91062d450f3c11c619187f0207bbb497fc89d265a46bbc6dc5f17c02a2b