Многомодульная зависимость maven с использованием репозитория, а не локального на Travis CI

У меня есть многомодульный проект, в котором один из двух подмодулей зависит от другого. Этот вопрос подразумевает, что mvn install должен позаботьтесь об этих зависимостях.

На моей машине все работает нормально на локальном уровне (как внутри Eclipse, так и в командной строке). Однако, когда я обновляю модуль, который изменяет код, необходимый второму модулю, и фиксирую его в моем репозитории github, второй модуль не удается выполнить сборку Travis CI. Я проследил проблему до того факта, что он загружает свою зависимость из репозитория, а не использует только что скомпилированный.

Проблема очень похожа на тот, о котором сообщается в этом вопросе, за исключением того, что вместо моего локального репозитория я имею дело с автоматической сборкой Travis CI. Комментарии и ответ на этот вопрос показывают, что:

Зависимость имеет версию моментального снимка. Для моментальных снимков Maven проверит локальный репозиторий и, если артефакт, найденный в локальном репозитории, слишком старый, попытается найти обновленный в удаленных репозиториях.

Однако в этом случае «слишком старый» не должен применяться. Местный артефакт был буквально только что построен. Ему должно быть несколько секунд.

Вот соответствующие разделы pom.xml модуля oshi-json, отметив его зависимость от oshi-core (оба имеют общий номер версии с родителем):

<parent>
    <groupId>com.github.dblock</groupId>
    <artifactId>oshi-parent</artifactId>
    <version>3.0-SNAPSHOT</version>
</parent>

<artifactId>oshi-json</artifactId>
<packaging>jar</packaging>

<name>oshi-json</name>

<dependencies>
    <dependency>
        <groupId>${project.groupId}</groupId>
        <artifactId>oshi-core</artifactId>
        <version>${project.version}</version>
    </dependency>
</dependencies>

И выдержка из родительского pom.xml:

<groupId>com.github.dblock</groupId>
<artifactId>oshi-parent</artifactId>
<version>3.0-SNAPSHOT</version>
<packaging>pom</packaging>

<name>oshi-parent</name>

<modules>
    <module>oshi-core</module>
    <module>oshi-json</module>
</modules>

Полные файлы доступны здесь:

Соответствующие выдержки из файлов журнала показаны ниже. Полный пример неудачной сборки Travis CI можно найти здесь. Обратите внимание, что симптом (ошибка компиляции) является результатом того, что Трэвис использует последний снимок для oshi-core, который не включает класс, указанный в oshi-json; однако класс находится в отправленном запросе на вытягивание и компилируется (и собирается с помощью mvn install) локально.

Когда я делаю новый коммит, Трэвис выполняет сборку следующим образом:

$ mvn install -DskipTests=true -Dmaven.javadoc.skip=true -B -V

Реактор правильно расставляет сборки по порядку:

[INFO] Reactor Build Order:
[INFO] 
[INFO] oshi-parent
[INFO] oshi-core
[INFO] oshi-json

Родитель строит, а затем oshi-core строит, локально сохраняя скомпилированный код:

[INFO] Строительная банка: /home/travis/build/dblock/oshi/oshi-core/target/oshi-core-3.0-SNAPSHOT.jar

Это банка, от которой я хочу, чтобы следующий модуль зависел. Однако, когда запускается сборка oshi-json, вместо этого он загружает артефакт из maven:

[ИНФО] Загрузка: https://oss.sonatype.org/content/repositories/snapshots/com/github/dblock/oshi-core/3.0-SNAPSHOT/oshi-core-3.0-20160624.032041-9.jar

[ИНФО] Загружено: https://oss.sonatype.org/content/repositories/snapshots/com/github/dblock/oshi-core/3.0-SNAPSHOT/oshi-core-3.0-20160624.032041-9.jar (199 КБ при 708,5 КБ/с)

РЕДАКТИРОВАТЬ: Только что заметил следующее предупреждение, которое появляется непосредственно перед загрузкой, которое может иметь или не иметь отношения (ошибка в настройках Travis), однако исправление этого предупреждения по-прежнему не решает мою проблему, вот неудачная сборка без предупреждения:

[ВНИМАНИЕ] Не удалось передать com.github.dblock:oshi-core:3.0-SNAPSHOT/maven-metadata.xml из https://nexus.codehaus.org/snapshots/ был закэширован в локальном репозитории, повторная попытка разрешения не будет предприниматься до тех пор, пока не истечет интервал обновления моментальных снимков codehaus или обновление не будет принудительным. Исходная ошибка: не удалось передать метаданные com.github.dblock:oshi-core:3.0-SNAPSHOT/maven-metadata.xml из/в codehaus-snapshots (https://nexus.codehaus.org/snapshots/): nexus.codehaus.org

Это временная проблема, связанная только с Travis-CI; установка pom будет работать нормально, как только я действительно выпущу все модули, и я могу обойти это, локально выполнив mvn clean deploy, чтобы отправить новый oshi-core в репозиторий OSS, чтобы Трэвис был счастлив. Однако это кажется плохим обходным путем.

Есть ли способ, которым я могу сказать Travis CI использовать только что скомпилированную банку, а не загружать новую, и сделать это таким образом, чтобы не прерывать предполагаемую загрузку зависимости из репозитория после ее публикации?


person Daniel Widdis    schedule 24.06.2016    source источник
comment
Можешь дать из всех актуальных модулей pom файлы а то сложно что-то полезное сказать. во время сборки нескольких модулей он не должен ничего откуда-либо скачивать, потому что он будет решаться из реактора.   -  person khmarbaise    schedule 25.06.2016
comment
@khmarbaise Я расширил выдержки и дал ссылки на исходные помпы (и неудачную сборку) на моем сайте github. Вероятно, вы можете разветвить исходный проект, чтобы поэкспериментировать локально, если хотите.   -  person Daniel Widdis    schedule 25.06.2016


Ответы (1)


Итак, хорошо, я более подробно изучил вашу сборку, позвольте мне обобщить некоторые из моих мыслей здесь:

Я обнаружил, что вы настроили maven-clean-plugin с разными значения, которые не являются необходимыми и не имеют преимуществ. Используйте парадигму Convention over Configuration. Нарушайте его только в том случае, если у вас есть действительно веская причина (честно говоря, я ее не вижу. Может быть, вы можете это объяснить).

Вы настроили maven-source-plugin для запуска в течение жизненного цикла по умолчанию, что означает, что он будет работать с каждым mvn clean package или с mvn install, что обычно не требуется, потому что исходные пакеты обычно нужны только в том случае, если вы делаете выпуск и передаете его в Maven Central . Кроме того, вы настроили использование цели jar maven-source-plugin, которая разветвляет жизненный цикл, что означает запуск некоторых частей с самого начала. Лучше всего удалить разветвленную цель жизненного цикла. Лучше всего добавлять исходные пакеты только во время выпуска релиза. (Обратите внимание, что вы отключили использование профиля выпуска).

Итак, приходите к maven-javadoc-plugin. Вы привязали его так, что он будет запускаться каждый раз через mvn clean package или mvn install. Я бы рекомендовал запускать это только в течение site жизненного цикла, потому что создание javadoc занимает много времени...

По какой причине у вас есть конфигурация wagon-ssh в качестве расширений? Какова цель этого? Если нужно опубликовать сгенерированный сайт на github, лучше воспользоваться плагином Maven SCM Publish намного проще и быстрее.

Вы также настроили maven-assembly-plugin с некоторыми странными свойствами src.relative.loc. Если у вас действительно есть один дескриптор, который можно использовать повторно, вам следует взглянуть на ссылку документация по общим дескрипторам. Объявление maven-assembly-plugin в родительском элементе означает, что он будет выполняться для всех pom, включая родительский, который выдает следующие предупреждения в вашей сборке:

[INFO] --- maven-assembly-plugin:2.6:assembly (oshi-assembly) @ oshi-parent ---
[WARNING] Cannot include project artifact: com.github.dblock:oshi-parent:pom:3.0-SNAPSHOT; it doesn't have an associated file or directory.
[INFO] Building tar: /Users/kama/ws-git-so/oshi/target/oshi-parent-3.0-SNAPSHOT-oshi-assembly.tar.gz
[WARNING] Cannot include project artifact: com.github.dblock:oshi-parent:pom:3.0-SNAPSHOT; it doesn't have an associated file or directory.
[INFO] Building tar: /Users/kama/ws-git-so/oshi/target/oshi-parent-3.0-SNAPSHOT-oshi-assembly.tar.bz2
[WARNING] Cannot include project artifact: com.github.dblock:oshi-parent:pom:3.0-SNAPSHOT; it doesn't have an associated file or directory.
[INFO] Building zip: /Users/kama/ws-git-so/oshi/target/oshi-parent-3.0-SNAPSHOT-oshi-assembly.zip
[INFO]                                                                         

Ах... очень важно: вы используете цель assembly, которая устарела и не должна использоваться. Используйте единственный существующий: single больше ничего. Причина assembly также разветвляет жизненный цикл, что замедляет сборку.

Я не уверен, что вам нравится производить здесь? Бинарный дистрибутив? Если это так, вы должны создать отдельный модуль, который называется что-то вроде oshi-dist, который содержит конфигурацию maven-assembly-plugin и может содержать другую информацию, связанную с распространением, например сценарии и т. д. И затем создание должно обрабатываться как это. Это связано с разделением ответственности. Почему сгенерированный сайт должен быть частью этого?

Кстати: каждый плагин, который определен в <build><plugins>..., будет унаследован всеми дочерними элементами и будет выполняться, что обычно не так. Исполняемые плагины должны определяться соответствующим типом упаковки, который указан в файле pom.

Обновление: почему вы настроили maven-scm-plugin?

Обновление 2: я создал PR ... чтобы вы могли более подробно изучить мои предложения ... Может быть, я пропустил некоторые части ваших потребностей ...

person khmarbaise    schedule 26.06.2016
comment
Спасибо за подробные комментарии и PR. Большая часть pom была заимствована из другого проекта и настроена для сборки одного проекта около года назад; некоторые из проблем, которые вы заметили, являются результатом того, что я просто пытался разделить вещи и заставить работать многомодульную сборку. Я посмотрю, исправят ли эти изменения проблему с локальным и репозиторием. - person Daniel Widdis; 27.06.2016
comment
Похоже, новая настройка pom исправила мою проблему, спасибо! Не делал шаг за шагом, чтобы точно увидеть, какая из многих ошибок вызвала это (вероятно, установка плагина исходного кода maven). Я буду продолжать работать над усовершенствованием помпона в соответствии с вашими предложениями здесь, но основная проблема решена. - person Daniel Widdis; 27.06.2016
comment
@khmarbaise я должен тебе пиво - person German Attanasio; 29.09.2016