java.lang.IllegalStateException: endPosTable уже установлен
Попытка построить набор навыков alexa (amazon:echo). В то же время, пытаясь использовать этот опыт в качестве учебного тестового стенда для внедрения зависимостей через кинжал 2. Тем не менее, собираем пакет с помощью maven-2 cmd:
mvn assembly:assembly -DdescriptorId=jar-with-dependencies package'.
Чтобы создать zip-архив с полными зависимостями, создается следующая трассировка исключений:
[INFO] ------------------------------------------------------------------------
[INFO] Building Echo Device Client 1.0
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ echo-device-client ---
[WARNING] Using platform encoding (UTF-8 actually) to copy filtered resources, i.e. build is platform dependent!
[INFO] skip non existing resourceDirectory /Users/apil.tamang/Dropbox/Git/echo-device-client/src/main/resources
[INFO]
[INFO] --- maven-compiler-plugin:3.3:compile (default-compile) @ echo-device-client ---
[INFO] Changes detected - recompiling the module!
[WARNING] File encoding has not been set, using platform encoding UTF-8, i.e. build is platform dependent!
[INFO] Compiling 46 source files to /Users/apil.tamang/Dropbox/Git/echo-device-client/target/classes
An exception has occurred in the compiler (1.8.0_60). Please file a bug at the Java Bug Database (http://bugreport.java.com/bugreport/) after checking the database for duplicates. Include your program and the following diagnostic in your report. Thank you.
java.lang.IllegalStateException: endPosTable already set
at com.sun.tools.javac.util.DiagnosticSource.setEndPosTable(DiagnosticSource.java:136)
at com.sun.tools.javac.util.Log.setEndPosTable(Log.java:350)
at com.sun.tools.javac.main.JavaCompiler.parse(JavaCompiler.java:667)
at com.sun.tools.javac.main.JavaCompiler.parseFiles(JavaCompiler.java:950)
at com.sun.tools.javac.processing.JavacProcessingEnvironment$Round.<init>(JavacProcessingEnvironment.java:892)
at com.sun.tools.javac.processing.JavacProcessingEnvironment$Round.next(JavacProcessingEnvironment.java:921)
at com.sun.tools.javac.processing.JavacProcessingEnvironment.doProcessing(JavacProcessingEnvironment.java:1187)
at com.sun.tools.javac.main.JavaCompiler.processAnnotations(JavaCompiler.java:1170)
at com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:856)
at com.sun.tools.javac.main.Main.compile(Main.java:523)
at com.sun.tools.javac.api.JavacTaskImpl.doCall(JavacTaskImpl.java:129)
at com.sun.tools.javac.api.JavacTaskImpl.call(JavacTaskImpl.java:138)
Первоначальная компиляция происходит нормально, и все тесты запускаются и успешно выполняются. Я чувствую, что во время "связывания" зависимостей дела идут на юг. Пожалуйста, посмотрите на этот файл, чтобы увидеть вывод консоли во время сборки.
Мой вопрос: стоит ли попытаться сгенерировать зависимости другим способом? Я не знаю много о Maven для этой цели. Есть ли патч или что-то еще, что можно использовать? Как вы думаете, возможно ли даже придумать обходной путь? Я хотел бы иметь возможность продолжать использовать каркас кинжала 2 для создания этого проекта.
6 ответов
Проблема описана в отчете об ошибке JDK-8067747:
(Ян Лахода)
Насколько мне известно, есть два аспекта этой ошибки:
ошибка javac, что он падает с исключением. Я работаю над этим, но, пожалуйста, обратите внимание, что javac не скомпилирует ввод, когда это будет исправлено, он выдаст соответствующее исключение из Filer (см. Ниже).
то, что кажется ошибкой maven: когда проект компилируется с помощью "чистой установки", процессор аннотаций сгенерирует исходный файл в "target/generate-sources/annotations". Когда инкрементная компиляция завершена, этот сгенерированный файл передается в javac в качестве входных данных, и процессор аннотаций попытается сгенерировать его снова, что недопустимо.
Это означает, что когда ошибка Maven исправлена, javac Ошибка сообщения о проблеме с неуместным исключением становится неактуальной. Однако, учитывая фактическую дату окончания срока службы Maven 2, я сомневаюсь, что вы можете ожидать найти исправление или патч для него.
Как объяснено в этой проблеме, обходной путь должен отключить useIncrementalCompilation:
<plugin>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<useIncrementalCompilation>false</useIncrementalCompilation>
</configuration>
</plugin>
В моем случае это произошло при создании файлов метаданных JPA с maven-processor-pluginплагин. Я создал файлы только один раз со специальным профилем Maven и добавил их в исходную папку.
Как отмечено в отчете об ошибке, это происходит, когда существующий файл должен снова компилироваться. Решение - удалить скомпилированные файлы передmaven-processor-pluginисполнение. Например:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-clean-plugin</artifactId>
<executions>
<execution>
<id>clean-jpa-model</id>
<phase>generate-sources</phase>
<goals>
<goal>clean</goal>
</goals>
<configuration>
<filesets>
<fileset>
<directory>
${project.basedir}/src/main/java
</directory>
<includes>
<include>**/model/*_.java</include>
</includes>
</fileset>
</filesets>
<excludeDefaultDirectories>true</excludeDefaultDirectories>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.8.0</version>
<executions>
<!--precompilation to find annotations and classed needed by the maven processor plugin for hibernate-jpamodelgen-->
<execution>
<id>compile-maven-processor</id>
<goals>
<goal>compile</goal>
</goals>
<phase>process-sources</phase>
<configuration>
<showDeprecation>false</showDeprecation>
<showWarnings>false</showWarnings>
<includes>
<include>**/model/*.java</include>
</includes>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.bsc.maven</groupId>
<artifactId>maven-processor-plugin</artifactId>
<version>3.3.3</version>
<executions>
<execution>
<id>generate-jpa-model</id>
<goals>
<goal>process</goal>
</goals>
<phase>generate-sources</phase>
<configuration>
<includes>
<include>**/model/*.java</include>
</includes>
<processors>
<processor>org.hibernate.jpamodelgen.JPAMetaModelEntityProcessor</processor>
</processors>
<outputDirectory>${project.basedir}/src/main/java</outputDirectory>
</configuration>
</execution>
</executions>
<dependencies>
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-jpamodelgen</artifactId>
<version>${hibernate.version}</version>
<scope>runtime</scope>
</dependency>
</dependencies>
</plugin>
Я столкнулся с той же ошибкой в проекте, который был создан и протестирован Maven и JDK 1.8.0_121. В исходной конфигурации проект был сначала очищен с помощью mvn clean, а затем построен с использованием mvn install -projectSpecificParameters и, наконец, протестирован с отдельным mvn install -otherProjectSpecificParameters, Эта конфигурация привела к ошибке, упомянутой в вопросе.
После изменения порядка этапов (сначала тестирование, а затем сборка) и добавление clean Цель команды build - очистить состояние сборки после тестов - ошибка больше не воспроизводилась.
Эта ошибка может произойти с процессорами аннотаций, а также во время компиляции. Я столкнулся с этим пару раз сmaven-processor-plugin:3.3.3/Мейвен 3.8.х.
Ответ Хольгера и анализ Лаходы верны, однако отключение добавочных сборок не является серебряной пулей, когда наблюдается эта ошибка, и не будет работать, если проблема связана с обработкой аннотаций.
Когдаorg.bsc.maven:maven-processor-plugin::processработает (при условииgenerate-sourcesЭтап) он ищет источники в настроенных корнях источников и записывает сгенерированные источники в другой настроенный корень источников (outputDirectoryэлемент конфигурации). Проблемы возникают, когда процессор аннотаций повторно считывает сгенерированные файлы как входные исходные файлы.
С конфигурацией по умолчанию
- сгенерированные исходники записываются в
target/generated-sources/apt - учитываются только основные источники проекта (
src/main/java)
Так что, как правило, все работает нормально, потому что сгенерированные источники не используются повторно для обработки.
В тех случаях, когда нам также необходимо генерировать исходники из файлов, сгенерированных другими плагинами, нам также необходимо включить их в обработку аннотаций. Конфигурация по умолчанию не поддерживает это, так как вы обычно генерируете что-то подtarget/generated-sources(например,target/generated-sources/db). Очевидным ответом на добавление сгенерированных источников является установкаtrue. Однако именно тогда вы получите пощечину с уже установленным endPosTable, так как эта опция будет включать исходный корень, созданный процессором аннотаций, в качестве входных данных для себя.
Самое простое решение, которое я нашел для этого, - сохранитьaddCompileSourceRootsкfalseи явно указать все дополнительные исходные корни. Например, это для создания классов метамодели для OpenJPA:
<plugin>
<groupId>org.bsc.maven</groupId>
<artifactId>maven-processor-plugin</artifactId>
<version>${bsc.maven.version}</version>
<executions>
<execution>
<id>process</id>
<goals>
<goal>process</goal>
</goals>
<phase>generate-sources</phase>
<configuration>
<additionalSourceDirectories>target/generated-sources/db</additionalSourceDirectories>
<addCompileSourceRoots>false</addCompileSourceRoots> <!-- not really needed as that's the default -->
<compilerArguments>-Aopenjpa.source=7 -Aopenjpa.metamodel=true</compilerArguments>
<processors>
<processor>org.apache.openjpa.persistence.meta.AnnotationProcessor6</processor>
</processors>
</configuration>
</execution>
</executions>
<dependencies>
<dependency>
<groupId>org.apache.openjpa</groupId>
<artifactId>openjpa</artifactId>
<version>${openjpa.version}</version>
</dependency>
</dependencies>
</plugin>
Я не уверен, может ли это помочь. Для моего случая у меня была такая же проблема с open-jdk8u91 Я установил oracle-jdk и смог запустить проект после mvn clean compile, Проблема заключалась в том, что я должен был переключаться между JDK для каждого запуска и строить его снова с помощью Maven.
РЕДАКТИРОВАТЬ: после двух дней борьбы с ним я обнаружил, что это результат несоответствия между maven а также jdk, Моя IDE использовала maven 3.0.5 в качестве связанного maven.
Решение: в вашей IDE вы должны изменить домашний каталог maven с bundled maven к вашей текущей версии, например /usr/share/maven, (для меня текущая версия была 3.3.9)