Не удалось выполнить цель org.apache.maven.plugins: maven-site-plugin: 3.7: site (default-cli): недопустимый тег байта в пуле констант: 18 - PullRequest
Новая
       8

Не удалось выполнить цель org.apache.maven.plugins: maven-site-plugin: 3.7: site (default-cli): недопустимый тег байта в пуле констант: 18

0 голосов
/ 30 мая 2018

Поскольку я не эксперт по Maven, я немного потерян здесь.У нас есть проекты, которые терпят неудачу со следующей ошибкой 

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-site-plugin:3.7:site (default-cli) on project xxxx: Execution default-cli of goal org.apache.maven.plugins:maven-site-plugin:3.7:site failed: Invalid byte tag in constant pool: 18 -> [Help 1]

при выполнении этой команды 

mvn site:site site-deploy -e -U

Это происходит, так как мы перешли на Java 8, и, насколько я понимаю, это как-то связано с Java 8 и BCEL .Однако сообщение в отчете об ошибке не совсем то же самое, поэтому я не уверен, как или что мне нужно настроить, чтобы решить эту проблему.

Здесь важная информация о том, как мы имеемнастроил сайт-плагин в родительском пом: 

<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-site-plugin</artifactId>
<version>3.6</version>
<configuration>
    <locales>en</locales>
</configuration>
<dependencies>
    <dependency>
        <groupId>org.apache.maven.wagon</groupId>
        <artifactId>wagon-webdav-jackrabbit</artifactId>
        <version>${wagon.webdav.version}</version>
    </dependency>
</dependencies>

1 Ответ

0 голосов
/ 30 мая 2018

На самом деле довольно глупая ошибка.Проблема была с использованным clirr, который был 2.3 

08:26:16 [INFO] <<< clirr-maven-plugin:2.3:clirr < compile @ xxxxx <<<

На самом деле clirr был настроен в родительском ПО для использования 2.8 

<plugin>
    <groupId>org.codehaus.mojo</groupId>
    <artifactId>clirr-maven-plugin</artifactId>
    <version>2.8</version>
</plugin>

Однако в локальном репозитории maven все еще былоустаревший родительский пом, который ссылался на 2.3 вместо 2.8.Удаление родительского pom из локального репо привело к повторной загрузке родительского pom, и теперь мы используем правильную конфигурацию

...