Статьи

Почему моя сборка Maven внезапно перестала работать?

Январь 24, 2019

Я хочу поделиться кое-чем разработчиком программного обеспечения или операционным парнем время от времени. И что я сделал вчера.

Все началось с нашей ночной Maven сборки неисправного в прошлую субботу 28 января на а

java.lang.NoClassDefFoundError: javax/xml/bind/ValidationEventLocator

Интересный фрагмент из вывода Concole из этой сборки выглядит следующим образом:

[INFO] <b>[jaxb2:generate {execution: xxx-schema-gen}] </b>[FATAL ERROR] org.jvnet.mjiip.v_2.XJC2Mojo#execute() caused a
linkage error (java.lang.NoClassDefFoundError) and may be out-of-date. Check the realms:
[FATAL ERROR] Plugin realm = app0.child-container[org.jvnet.jaxb2.maven2:maven-jaxb2-plugin]
urls[0] = file:/home/hudson/.m2/repository/org/jvnet/jaxb2/maven2/maven-jaxb2-plugin/0.8.1/maven-jaxb2-plugin-0.8.1.jar
urls[1] = file:/home/hudson/.m2/repository/org/jvnet/jaxb2/maven2/maven-jaxb2-plugin-core/0.8.1/maven-jaxb2-plugin-core-0.8.1.jar
urls[2] = file:/home/hudson/.m2/repository/com/sun/org/apache/xml/internal/resolver/20050927/resolver-20050927.jar
urls[3] = file:/home/hudson/.m2/repository/org/sonatype/plexus/plexus-build-api/0.0.7/plexus-build-api-0.0.7.jar
urls[4] = file:/home/hudson/.m2/repository/org/codehaus/plexus/plexus-utils/1.5.15/plexus-utils-1.5.15.jar
urls[5] = file:/home/hudson/.m2/repository/org/jfrog/maven/annomojo/maven-plugin-anno/1.3.1/maven-plugin-anno-1.3.1.jar
urls[6] = file:/home/hudson/.m2/repository/org/jvnet/jaxb2/maven2/maven-jaxb22-plugin/0.8.1/maven-jaxb22-plugin-0.8.1.jar
urls[7] = file:/home/hudson/.m2/repository/com/sun/xml/bind/jaxb-impl/2.2.5-b10/jaxb-impl-2.2.5-b10.jar
urls[8] = file:/home/hudson/.m2/repository/com/sun/xml/bind/jaxb-xjc/2.2.5-b10/jaxb-xjc-2.2.5-b10.jar
[FATAL ERROR] Container realm = plexus.core.maven

[INFO] ------------------------------------------------------------------------
[ERROR] FATAL ERROR
[INFO] ------------------------------------------------------------------------
[INFO] javax/xml/bind/ValidationEventLocator
[INFO] ------------------------------------------------------------------------
[INFO] Trace
java.lang.NoClassDefFoundError: javax/xml/bind/ValidationEventLocator
	at com.sun.tools.xjc.reader.internalizer.DOMForestScanner.scan(DOMForestScanner.java:84)

Кажется, что maven-jaxb2-plugin — мы используем JAXB для генерации java-источников для определенной схемы — внезапно вызывает (отсутствующую или несовместимую?) Зависимость. Странная вещь — это «внезапная» часть, так как последний коммит был сделан в пятницу, после чего нормальные непрерывные сборки работали нормально, а даже ночная сборка с полуночи с пятницы по субботу. Мы используем Maven, чтобы позаботиться об этих вещах, верно? Всегда есть известный набор зависимостей, каждая часть процесса?

Конечно, в то время вещи не казались такими очевидными. Первое, что меня интересует, может ли это быть связано с проблемой Java 5 против 6? Фактически, в нашем проекте мы пытаемся перейти на Java 6 после долгого времени, но я единственный, кто уже некоторое время обновлял мою локальную машину разработчика для работы с JDK6 и смотрю, ничего странного не происходит , Вы знаете, что многие файлы из вашего рабочего пространства хранятся в специальном рабочем наборе «НЕ ОБЯЗАТЕЛЬНО» или скрыты от просмотра, чтобы предотвратить их преждевременное попадание в систему контроля версий.;-)

Естественно, я сначала изучил все наборы изменений, приведшие к неудачной сборке, чтобы увидеть, не сделал ли я случайно файл, которого у меня не должно быть. Но я не мог ничего найти.

Затем я подумал: может ли Хадсон был неправильно настроен на прошлой неделе расставающимся сотрудником (который до своего ухода оставался несколько неофициальным владельцем нашей инфраструктуры CI), который теперь всплыл, потому что, например, сервер был перезапущен или Хадсон был обновлен? Проверил несколько вещей: наш Hudson startup.sh выглядел так

/usr/java/latest/bin/java -jar hudson.war --httpPort=9090 --ajp13Port=9091 --deamon --logfile=hudson.log &

где / usr / java / latest / bin / java указывает на «среду выполнения Java (TM) SE (сборка 1.6.0 _24-b07)», а обычная «java» в командной строке указывает на «среду выполнения Java (TM) 2» Environment, Standard Edition (сборка 1.5.0 _22-b03) ». Может ли быть так, что «последняя» директория, указанная ранее на Java 5 ru (путем какого-то таинственного обновления на сервере), теперь внезапно ссылается на Java 6. Может ли версия Java, с которой мы запускаем Hudson, повлиять на версию Java, которую мы используем для наших заданий Hudson?

Я не надеюсь на это! Следовательно, я проверил саму конфигурацию Hudson: какие JDK мы настроили? К счастью, только один: с именем «1_5_0», а JAVA_HOME указывает на «/ usr / java / default». Но опять же неясно из пути к какой версии Java он указывает, пока я не выяснил, что эта символическая ссылка ведет к «/usr/java/jdk1.5.0_22». Хорошо, JDK 5 должен использоваться по умолчанию для всех наших сборок Maven. Чтобы убедиться, что я добавил 2-ю поддельную запись JDK в конфигурацию Hudson, я смог явно выбрать ее в конфигурации задания — и после запуска новой сборки я был уверен, что Hudson настроен правильно с точки зрения JDK. Человек, как можно отвлечься!

Итак, давайте посмотрим на библиотеку-нарушителя под рукой. Из трассировки стека можно обнаружить артефакт maven-jaxb2-plugin из группы org.jvnet.jaxb2.maven2 . Что-то случилось с самой этой зависимостью? Я открыл консоль Nexus, искал ее и увидел экран ниже:

Подожди минуту! Почему у нас есть две версии этого плагина? В Nexus я открыл вкладку Информация об артефакте в версии 0.8.1 и увидел, что дата загрузки указана в последнюю субботу 28 января. Я знаю, что в Nexus не должно быть более одной версии этого плагина. Небольшая проверка на странице примечаний к выпуску JIRA этого плагина…

Ну тогда. Итак, в прошлую субботу был опубликован новый выпуск плагина, и ночная сборка вызвала загрузку новой версии 0.8.1, которая, похоже, была скомпилирована для Java 6, что вызвало java.lang.NoClassDefFoundError . Это естественно привело меня к оскорбительной части нашего pom.xml :

            <plugin>
                <groupId>org.jvnet.jaxb2.maven2</groupId>
                <artifactId>maven-jaxb2-plugin</artifactId>
            </plugin>

Argh. Нет версии!

Поменял это на:

            <plugin>
                <groupId>org.jvnet.jaxb2.maven2</groupId>
                <artifactId>maven-jaxb2-plugin</artifactId>
                <version>0.8.0</version>
            </plugin>

Я зафиксировал pom.xml и запустил ручную сборку — и … это сработало. Конечно.

В заключение, я думаю, что есть несколько уроков:

  • При отладке проблемы всегда старайтесь рассуждать о возможных путях, которые приходят вам в голову, чтобы следовать в первую очередь, и не зацикливайтесь на своей первой появившейся идее. Это заставило меня, я думаю, слишком долго отвлекаться на выяснение того, случайно ли я зафиксировал файлы Java 6, или же Хадсон был случайно неправильно настроен на то, чтобы больше не использовать Java 5. Навыки поиска и устранения неисправностей в значительной степени зависят от предыдущего опыта в данной области и, конечно, если возникнет подобная проблема, я смог бы быстрее ее распознать.
  • Запишите это — так что коллеге или вам самим будет легче найти его позже.
  • Explicity устанавливает версии зависимостей в вашем pom.xml! Не вините Maven за все;-)

У кого-нибудь еще есть рассказ о поиске неисправностей, идущий в неправильном направлении?

Исходное сообщение: http://tedvinke.wordpress.com/2012/02/01/why-does-my-maven-build-fail

54
Share: