Maven терпит неудачу в java 10 [duplicate]

Добавьте следующий фрагмент в свой pom.xml:

<build>
    <plugins>
        <plugin>
            <artifactId>maven-compiler-plugin</artifactId>
            <version>3.7.0</version>
            <configuration>
                <source>9</source>
                <target>9</target>
            </configuration>
        </plugin>
    </plugins>
</build>

Часть трассировки стека

at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.readSourceFile(JavaCompiler.java:821)

относится к строке кода

throw new CompletionFailure(c, diags.fragment("cant.resolve.modules"));

Это может произойти, если вы пытаетесь построить модуль maven, который не основан на Java9 и / или не имеет (правильного) объявления модуля module-info.java с версией выпуска, указанной как 9, где он не сможет разрешать модули с / без объявления.

UPDATE

В большинстве случаев эта ошибка возникает, когда компилятор пытается сообщить об ошибке компиляции, но он взрывается в процессе. До сих пор в основном два подхода помогли решить эти проблемы:

• Отключить обработку аннотаций с помощью аргумента компилятора -proc:none (похоже, что обработка аннотаций может нарушить компилятор, поэтому, если вы не предназначены для использовать любой, это бесплатный выигрыш).
• Отладить компилятор с помощью условной точки останова и пройти стек до получения сообщения об ошибке компилятора, а затем исправить эту ошибку ...

ORGINAL SOLUTION

После множества проб и ошибок я смог локально решить проблему / исправить эту проблему, в конце концов, мой подход был следующим:

• У меня было предположение, что, возможно, зависимости каким-то образом влияют на результат сборки, поэтому я начал комментировать записи Maven & lt; dependency> в POM отказавшего модуля.
• сборка затем начала сбой, но он сделал это с ожидаемым, не может найти символ и подобные ошибки компиляции вместо бесполезного сбоя AssertionError
• , оказалось, что существует один конкретный зависимостей, вызвавших этот AssertionError.
• После анализа кода я не мог определить, какая из веских причин, почему эта зависимость вызывает проблемы, поэтому я начал смотреть на транзитивные зависимости
• I, затем использовал тот же подход, что и раньше, но вместо того, чтобы раскомментировать ошибочную зависимость, я вложил все свои транзитивные зависимости в POM
• , сборка снова не удалась, и после многих и многих тестов оказалось, что Я мог бы вызвать AssertionError, когда и io.vavr: vavr: 0.9.0: compile и javax.servlet: servlet-api: 3.0.1: тест был включен в граф зависимостей

It по-прежнему не соответствует мне, как зависимость от тестовой области может повлиять на компиляцию проекта ... Также выяснилось, что javax.servlet: servlet-api: 3.0.1: предоставляется уже среди зависимостей модуля сбоя, а зависимость от тестируемой области фактически не использовалась ни для чего.

В итоге я просто удалил неправильно определенный тестовый сервлет et-api из модуля запуска ошибок, и вдруг Maven смог скомпилировать ранее провальный модуль.

Я уверен, что это очень неясный ответ на очень неясный вопрос, в первую очередь, но, надеюсь, мой подход будет полезен для кого-то другого.