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

Ответ 1

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

Это была теперь исправленная ошибка в пакете openjdk-8 (поведение значительно отклоняется от апстрима без необходимости; отсутствует вышестоящий патч для возврата к отключению проверки безопасности), до которого вы только что обновились. Но это также ошибка в плагине surefire, 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!

Ответ 2

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

Ответ 3

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

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

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

Ответ 4

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

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

Ответ 5

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

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

Ответ 6

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

Изменив его на maven:3.5.4-jdk-8-alpine проблему.

Ответ 7

Я перешел по этой ссылке 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

Ответ 9

Для тех, кто ищет ответ, связанный с 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.

Ответ 10

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

-DforkCount=0

Ответ 11

Для 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.

Ответ 12

Я недавно настроил 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"

Ответ 13

Я удалил 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

Ответ 14

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

Ответ 15

Я добавил зависимость к 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>

Ответ 16

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

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

image: maven:3.5.4-jdk-8

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

image: [email protected]:b37da91062d450f3c11c619187f0207bbb497fc89d265a46bbc6dc5f17c02a2b

Ответ 17

Я использую это как обходной путь для остановки компиляции и выполнения тестовых файлов:

-Dmaven.test.skip=true with maven