Не удается собрать Hadoop 2.4.1 с Java8

#maven #hadoop #java-8

#maven #hadoop #java-8

Вопрос:

Проблема довольно проста. Я пытаюсь скомпилировать Hadoop2.4.1 в Windows с помощью следующей команды :

 mvn clean package -Pdist,native-win -DskipTests -Dtar
  

С JAVA_HOME=C:Program FilesJavajdk1.7.0_51 это работает нормально.

С JAVA_HOME=C:Program FilesJavajdk1.8.0_05 этого не происходит, и сбой выдает мне следующую ошибку :

 [INFO] Apache Hadoop Annotations ......................... FAILURE [4.086s]
---
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-javadoc-plugin:2.8
.1:jar (module-javadocs) on project hadoop-annotations: MavenReportException: Er
ror while creating archive:
[ERROR] Exit code: 1 - C:hadoop-srchadoop-common-projecthadoop-annotationssr
cmainjavaorgapachehadoopclassificationInterfaceStability.java:27: error:
unexpected end tag: </ul>
[ERROR] * </ul>
[ERROR] ^
[ERROR]
[ERROR] Command line was: "C:Program FilesJavajdk1.8.0_05jre..binjavadoc.
exe" -J-Dhttp.proxySet=true -J-Dhttp.proxyHost=proxy -J-Dhttp.proxyPort=3128 @op
tions @packages
[ERROR]
[ERROR] Refer to the generated Javadoc files in 'C:hadoop-srchadoop-common-pro
jecthadoop-annotationstarget' dir.
[ERROR] -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e swit
ch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please rea
d the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionE
xception
[ERROR]
  

Как указывалось ранее, я ничего не изменил, кроме JAVA_HOME . Сообщение об ошибке, похоже, указывает на то, что ошибка связана с прокси, но я понятия не имею, почему.

В обоих случаях у меня есть

 C:hadoop-src>javac -version
javac 1.8.0_05
  

и

 C:hadoop-src>java -version
java version "1.8.0_05"
Java(TM) SE Runtime Environment (build 1.8.0_05-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.5-b02, mixed mode)
  

Ребята, у вас есть какие-нибудь подсказки о том, что происходит?

Ответ №1:

В качестве альтернативы предложению Стюарта (мне было трудно выяснить, куда поместить additionalparam): чтобы вообще пропустить генерацию javadoc, просто запустите

 mvn clean package -Pdist,native-win -DskipTests -Dtar -Dmaven.javadoc.skip=true
  

Ответ №2:

Об этой ошибке сообщает javadoc. Версия javadoc в Java 8 значительно более строгая, чем в более ранней версии. Теперь он выдает ошибку, если обнаруживает то, что он считает недопустимой разметкой, включая наличие конечного тега, где он не ожидается.

Чтобы отключить эту проверку в javadoc, добавьте -Xdoclint:none флаг в командную строку javadoc. Информацию о том, как это сделать в среде maven, смотрите в записи в блоге Стивена Коулборна на эту тему. В частности, добавить

 <additionalparam>-Xdoclint:none</additionalparam>
  

в соответствующие свойства или файл конфигурации.

Однако происходит пара странных вещей. Текущая (магистральная) версия этого файла, похоже, имеет </ul> тег end в нужном месте. История этого файла указывает на то, что ранее отсутствовавший конечный тег был добавлен сравнительно недавно, но, похоже, он есть в Hadoop 2.4. И этот файл сам по себе успешно обрабатывается JDK 8u5 javadoc без необходимости подавления каких-либо ошибок.

Был ли где-нибудь применен патч, который добавил ранее отсутствовавший </ul> конечный тег, который теперь является избыточным, поскольку конечный тег был добавлен в исходный код? Дополнительный конечный тег приведет к сбою javadoc с этой ошибкой.

Обновить

Я смотрел не на ту ветку. В версии 2.4.1 этого файла явно есть дополнительный </ul> конечный тег. Мое предположение об ошибочном исправлении было отчасти правильным. История файла на магистрали показывает, что множество комментариев javadoc были добавлены еще в июне 2012 года HADOOP-8059. В этих новых дополнениях отсутствовал </ul> тег end. В январе 2014 года в HADOOP-10320 был добавлен отсутствующий конечный тег. Исправление для HADOOP-10320 было перенесено в ветку 2.4.1, но новые javadocs из HADOOP-8059 не были перенесены, что привело к неправильной разметке.

Комментарии:

1. Нет исправления, о котором я знаю. Я только что загрузил архив с исходным кодом 2.4.1 с веб-сайта apache (который не был изменен с 21 июня). Я проверил тот же файл в src и обнаружил некоторые другие несоответствия (отсутствие трех импортированных файлов). Документ также не тот, и действительно есть неправильно размещенный </ul> .

2. @fxm Ах, я понял это. Обновит ответ. Но -Xdoclint:none обходной путь тот же, если только вы не хотите напрямую взломать исходный файл.

3. Безусловно, я принял ваш ответ, как только мне удалось все скомпилировать :). Спасибо, что еще немного покопались, приятно это знать!