Maven верный не мог найти класс ForkedBooter


218

Недавно, приходя в новый проект, я пытаюсь скомпилировать наш исходный код. Вчера все работало нормально, а сегодня другая история.

Каждый раз, когда я работаю mvn clean installс модулем, попадаю в тесты, он выдает ошибку:

[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

и позже:

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

Я использую 64-разрядную версию Debian 9 (Stretch) с OpenJDK 1.8.0_181, Maven 3.5.4 и работаю за прокси-сервером моей компании, который я настроил в своем ~/.m2/settings.xml.

Странно то, что последняя версия Surefire - 2.22.1, если я правильно помню. Я попытался указать версию плагина, но он не обновляется, иначе нет никакой спецификации версии плагина ни в одном POM (parent, grand-parent или этот).

Мне удалось заставить Maven изменить версию Surefire на последнюю, но теперь это еще хуже:

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

1
У меня эта ошибка в Clircle-CI. Surefire разветвляется и разветвляется vm печатает следующее сообщение и завершает работу: «Ошибка: не удалось найти или загрузить основной класс org.apache.maven.surefire.booter.ForkedBooter». Массаж находится в target / surefire-reports / *. Dumpstream. Если вы запускаете maven с -X, он печатает командную строку, вы можете попробовать и увидеть, как vm печатает это сообщение.
Бруно Коутиньо


Мое решение было прекратить использовать open-jdks любой версии. не может позволить себе такого рода ненадежность в чем-то столь фундаментальном.
Адриан М.

Используйте dependencyManagementраздел maven для указания различных версий плагинов
jogaco

Обновление до jdk 11 в Debian было для меня верным решением!
ясный свет

Ответы:


251

Чтобы исправить это (в 2018 году), обновите ваш openjdk до последней версии, по крайней мере, 8u191-b12. В случае, если эта проблема вновь появится в 2020 году, вполне вероятно, что поведение openjdk по умолчанию было изменено, и вам потребуется обновить плагин maven surefire.

Это была теперь исправленная ошибка в пакете openjdk-8 (поведение значительно отклоняется от апстрима без необходимости; отсутствует патч апстрима для возврата к отключению проверки безопасности), до которого вы только что обновились. Но это также ошибка в безошибочном плагин, SUREFIRE-1588 , предположительно , зафиксированные в SUREFIRE 3.0.0-M1 : он , по- видимому использует абсолютные пути в месте , где Java будет в будущем только позволит имена относительного пути (и Debian активизированы будущее поведение уже).

Версия пакета 8u181-b13-2 гласит:

  • Примените исправления из обновления безопасности 8u191-b12.

Обратите внимание, что 191-b12! = 181-b13. Исправления безопасности 191-b12 были выпущены всего несколько дней назад, и, очевидно, сопровождающие хотели их быстро достать. Полное обновление до 191-b12, вероятно, потребует дополнительного тестирования (ну, так что, очевидно, должен иметь эту загрузку).

Было несколько обходных путей:

  1. Вместо этого вы можете установить предыдущий пакет из snapshots.do . После понижения версии вы можете запретить использование сломанной версии (если вы используете aptitude, а не apt) sudo aptitude forbid-version openjdk-8-jre-headless. Для обычного «apt» я не видел аналогичного механизма запрета, поэтому вам, вероятно, нужно будет использовать apt-пиннинг, чтобы предотвратить переустановку этого обновления (или вы просто продолжаете понижать версию, надеюсь, это скоро будет решено).
  2. Согласно отслеживанию ошибок, установка свойства -Djdk.net.URLClassPath.disableClassPathURLCheck=trueлюбым из обычных методов (например, JAVA_FLAGS) также должна помочь. Но я не проверял это сам. Очевидно, вы даже можете добавить обходной путь, чтобы~/.m2/settings.xml легко включить его для всех ваших сборок Maven.

Как видите, отслеживание ошибок работает , проблема сузилась, и доступен фиксированный пакет, и скоро выйдет новая версия плагина surefire!


@AdrianMadaras До сих пор я не получил новое обновление, только версия -2. Там также не было никакого объявления о фиксированной загрузке, но она продолжается. Вы, вероятно, только что обновили до известной проблемной версии.
Эрих Шуберт

1
Я только что получил ту же проблему на Ubuntu 18.04, используя OpenJDK 10.0.2. Переключение JAVA_HOME к моей установке 'java-9-oracle' исправило это.
RobAu

2
Вот соответствующая проблема в трекере ошибок surefire -maven-plugin: questions.apache.org/jira/browse/SUREFIRE-1588 (это все еще ошибка в бэкпорте Canonical / Debian соответствующих изменений OpenJDK).
Мирабилось

1
Обойти 1. не имеет смысла для меня, так как это версия, на которой я испытываю проблему. Переопределение maven-surefire-plugin для того, чтобы не использовать SystemClassLoader, также не работало
Эдвин Диас-Мендес,

1
Вы также можете попробовать обновить до версии 3.0.0-M1. Но версия от 2 до 3 этапов, конечно, может сломать другие вещи.
Эрих Шуберт

54

Установите для useSystemClassloader значение false:

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

Если вы не наследуете от родителя, для которого определена версия (например, стартовая версия Spring Boot), вам также необходимо определить это.


Включение системного загрузчика классов является наихудшей практикой, поскольку вы запускаете тесты в процессе плагина. Правильная практика - обновить версию каждого плагина. Maven 3.7.0 обновит версии всех плагинов, которые относятся к жизненному циклу по умолчанию. Spring не должен придерживаться старых версий и не должен их переопределять. Это вызывает ненужные конфликты в обязанностях.
tibor17

52

Я нашел этот обходной путь и исправил свои тесты: настроить maven-surefire-pluginне использовать системный загрузчик классов.


По словам сопровождающего maven-surefire-plugin, все обходные пути (это, установка forkCount0 или argLineглобальная настройка ) имеют проблемы и не могут применяться универсально.
Мирабилось

Хорошая находка. Но, пожалуйста, включите фактический обходной текст в ваше сообщение или, по крайней мере, четко определите ссылку как ссылку на стек-поток. То есть подход @markoorn более полезен.
nealmcb

38

У меня есть другой обходной путь. Установите переменную среды _JAVA_OPTIONS. Я использовал это для наших агентов сборки TeamCity, и теперь наши сборки работают нормально.

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

Крайнее изменение, помеченное как исправление безопасности, обычно не вводится ни по какой причине, и поэтому кто-то говорит на SO, как его отключить ... просто скажите
berezovskyi

26

Я опубликовал более целевой вариант одного из описанных выше обходных путей в JIRA . Добавить к ~/.m2/settings.xml:

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

Это терпит неудачу со следующим предупреждением:[WARNING] Expected root element 'settings' but found 'profile' (position: START_TAG seen <profile>... @1:9) @ /home/nikolai/.m2/settings.xml, line 1, column 9
Николай

3
@Nikolai Приведенный выше фрагмент должен быть заключен в <settings><profiles>...</profiles></settings>.
qqx

13

У меня была эта проблема в моей сборке GitLab CI, которая использовала maven:3.5.4-jdk-8образ Docker.

Изменение это, чтобы maven:3.5.4-jdk-8-alpineисправить проблему.


8

Я перешел по этой ссылке https://maven.apache.org/surefire/maven-surefire-plugin/examples/class-loading.html и добавил следующий плагин в pom.xml, и он работал,

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

8

При использовании GitLab CI / CD с 3.6.0-jdk-8изображением помогло только свойство ниже (без изменений pom.xml).

-Dsurefire.useSystemClassLoader=false

Это опять плохая практика. Правильный вариант - обновить версию. Всегда проверяйте версии в Maven Central .
tibor17

5

Для тех, кто ищет ответ, связанный с Docker Maven: 3.5.x-jdk-8 в GitLab CI, посмотрите эту проблему GitHub .

Похоже, 3.5.4-jdk-8изображение привело к обновлению до минорной версии Java, что каким-то образом влияет на механизм разветвления Surefire.

Откат к 3.5.3-jdk-8изображению исправил это на моем сервере GitLab CI, создавая код Java 1.8 с Surefire 2.20.1.


5

Приведенное выше предложение установить свойство "-Djdk.net.URLClassPath.disableClassPathURLCheck = true" не сработало для меня, но установка следующего работает нормально:

-DforkCount=0

2
Это приводит к тому, что новая виртуальная машина не создается для запуска тестов, поэтому тесты могут влиять на основную виртуальную машину сборки.
Paŭlo Ebermann

4

Для Ubuntu: установите последнюю версию, эта ошибка исправлена

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

Установите последнюю рабочую версию (без исправлений безопасности) без ошибок.

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

Если вы пропустили эту версию, используйте версию до этого:

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

Затем используйте закрепление или следите за тем, чтобы не установить неработающую версию.

Использование -Djdk.net.URLClassPath.disableClassPathURLCheck=trueне работало для меня, куда бы я ни поместил эту конфигурацию. Где-то в моих интеграционных тестах он всегда выходил без старой версии Java.

Как упоминал Эрих , это ошибка в пакете Debian, которая слишком строга 911925, и плагин Surefire не работает в соответствии с новыми правилами SUREFIRE-1588 .


Зачем кому-то предлагать установить версию без исправлений безопасности ?! Хотя другие предложения включают пропуск тестов, да.
Березовский

1
Вам больше не нужно :-) Это исправлено. Но в то же время у меня было много java-проектов, над которыми мне приходилось работать, и моя среда выполнения java нигде не подверглась воздействию какого-либо нового кода извне. Таким образом, был очевидный риск, который был приемлем для меня. В конце концов, это решение каждого :-)
flob

На самом деле вы правы, я обнаружил, что разработчики JDK вернулись на этот набор опор по умолчанию: hg.openjdk.java.net/jdk/jdk/rev/f54dcfc5a5f8 ; но обновление основной версии до верного мне не кажется лучшим решением на самом деле.
Березовский

1
Абсолютно! Но изменения, которые они должны были сделать, распространены по всей базе кода и очень агрессивны. Таким образом, незначительное изменение версии для этого исправления не было бы верным вариантом.
флоп

1
И, к сожалению, выпуск 2.x снят с производства, и нам придется переключиться раньше, чем позже: questions.apache.org/jira/browse/…
berezovskyi

2

Я добавил зависимость к junit-jupiter-engine, и это сработало.

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

Какую черную магию делает этот плагин Юпитер? Это сработало для меня! Upvote! :-)
Хинотори

1

Я недавно настроил Maven Job на Jenkins и застрял в той же проблеме. Я принял предложение изменить переменную JAVA env и подтвердить, что проблема решена. Это как я проверял.

Станьте пользователем "jenkins" и измените папку на имя проекта рабочей области, которое вы настроили для работы.

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

Добавив это в maven-surefire-plugin, я решил проблему:

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

1

По сути, это несовместимость между версией JDK и версией плагина maven-surefire, в моем случае JDK 11.0.5 не работает с верным 3.0.0-M4, мне пришлось переключиться на 3.0.0-M3, и это сработало. установка 0 для forkCount не решает проблему, потому что она нарушает отчет Jacoco.


0

Я удалил JDK, который входит в репозитории:

$ sudo apt purge openjdk-8-jdk

$ sudo apt autoremove

Затем я удалил JAVA_HOMEпеременную среды. Мой был установлен в моем .bashrc.

Затем я переустановил его через SDKMAN:

$ sdk install java 8.0.181-zulu

С их сайта :

SDKMAN! это инструмент для управления параллельными версиями нескольких комплектов разработки программного обеспечения в большинстве систем на основе Unix. Он предоставляет удобный интерфейс командной строки (CLI) и API для установки, переключения, удаления и вывода списка кандидатов.

Чтобы увидеть другие версии JDK для установки, используйте:

$ sdk list java

0

Я столкнулся с той же проблемой с gitlab ci, меняя образ maven с maven:3-jdk-8на, maven:3.6.0-jdk-8-alpineкажется, чтобы решить проблему. Кстати, я также проверил, maven:3.6.0-jdk-8но это не сработало.


0

Это все еще проблема для surefire - v2.22.2с maven:3.6-jdk-8-alpine. Чтобы решить эту проблему, добавьте следующий код pom.xml(как плагин maven)

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

-1

Если, как и я, у вас есть проблемы в вашем конвейере (для меня это в GitLab, но неважно) и если вы используете образ Maven JDK 8 Docker.

Вы можете заменить

image: maven:3.5.4-jdk-8

последней рабочей сборкой

image: maven@sha256:b37da91062d450f3c11c619187f0207bbb497fc89d265a46bbc6dc5f17c02a2b

1
Проблема возникла в последней версии jdk8 для Debian. На мой взгляд, лучше «исправить» основную проблему, чем пытаться ее обойти.
Силордис

Sha256 звучит сложно и боится тебя? На самом деле другой ответ выглядит скорее как обходной путь, отключите некоторые функции от верного, здесь речь идет только об использовании последнего рабочего образа докера без изменения рабочей пометки или конвейера, что является обходным решением.
amdev
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.