maven развернуть только измененные артефакты

Question

Я использую Maven 2.2 с Nexus 1.4.0

Допустим, у меня есть такая структура pom (с соответствующими версиями)

parentproj, v1.0.1
 - childproj1, v1.0.2
 - childproj2, v1.0.7

childproj1 и childproj2 представляют разные части приложения (например, графический интерфейс пользователя и серверную часть), и я хочу иметь возможность хранить их версии отдельно, чтобы я мог выпускать новую версию серверной части без необходимости выпускать новую версию графического интерфейса.

Теперь, чтобы развернуть эту структуру в Nexus, было бы удобно перейти к parentproj и сказать:

mvn deploy -DperformRelease=true

который развернет все артефакты в хранилище Nexus Realease. Это работает нормально при первом развертывании, но во второй раз я сталкиваюсь с проблемами: допустим, я сделал обновление для childproj1, так что теперь у нас есть следующие версии:

parentproj, v1.0.1
 - childproj1, v1.0.3
 - childproj2, v1.0.7

В этой ситуации Nexus не позволит мне выполнить mvn deploy из parentproj, так как у него уже есть копия childproj2 в версии 1.0.7. Nexus скажет: "Ресурс, недопустимый запрос: хранилище с идентификатором ="Releases "не позволяет обновлять артефакты". Это нормально, я не хочу обновлять существующие версии по ошибке.

Но я думаю, что я хотел бы сказать maven что-то вроде "развернуть только те артефакты, у которых есть версии, которых еще нет в репозитории выпусков".

Есть ли способ сделать это, или я должен был бы развернуть каждый проект отдельно?

Answer 1

По моему опыту, было проще развернуть все и часто использовать один и тот же номер версии для всех компонентов. Например, если моя команда работает над версией 1.0.7, все подмодули имеют номер версии 1.0.7-SNAPSHOT, пока мы не выпустим, даже если код не был изменен в определенных модулях. Затем, когда мы развернем, мы развернем все приложение. Я думаю, что у этого есть несколько преимуществ по частичному развертыванию. Во-первых, если вам нужно откатиться до последней стабильной версии, вам просто нужно откатиться до 1.0.6 для всех модулей - вам не нужно помнить, что бэкэнд был 1.0.3, а GUI - 1.0.6. Во-вторых, он гарантирует, что все компоненты правильно скомпилированы и протестированы как логическая группа.

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

Answer 2

Прежде всего, я думаю, что вы должны различать родительский проект и проект агрегации. Родительские проекты должны использоваться для тех настроек, которые являются общими для нескольких проектов, например, версии зависимостей; агрегационные проекты должны использоваться для того, чтобы одновременно создать группу проектов, например, набор банок и войну, в которую они входят.

Два вида проектов лучше всего хранить отдельно. Родительский проект обычно меняется не очень часто, и когда это происходит, обычно лучше выпускать новые версии всех проектов, которые зависят от него; Единственная цель проекта агрегации состоит в том, чтобы управлять сборкой нескольких проектов, поэтому номер его выпуска, вероятно, должен меняться всякий раз, когда необходимо выпустить один из содержащихся в нем проектов.

После того, как вы отделили родителя от агрегатора, вы в лучшем положении, чтобы выбрать, следовать ли совету Джона Полетта и держать все под тем же номером версии, или пытаться изменить номер версии каждого проекта только тогда, когда вам действительно нужно его выпустить. Первый вариант проще и менее подвержен ошибкам, но заставляет выпускать новые версии библиотек, которые не изменились. Это может быть неприемлемо, если, например, вам необходимо поставлять исправления, а не полные выпуски. Второй вариант более сложен и подвержен ошибкам, но приводит к тому, что номера ваших выпусков соответствуют эволюции вашего программного обеспечения. Здесь могут помочь плагин релиза Maven и инструмент непрерывной интеграции Jenkins, думаю, вам стоит их проверить. Также посмотрите, можете ли вы обновить Maven до версии не ниже 2.2.1, а Nexus до более новой версии.

Answer 3

Я бы предложил вам подключить плагин Artifact Exists Maven ( https://github.com/chonton/exists-maven-plugin). Эта замечательная вещь требует упоминания только в parent.pom и автоматически пропустит фазу установки и развертывания всех артефактов выпуска, которые уже существуют в репозитории (Nexus или Artifactory). И все же развернуть снимки (это настраивается).

Пример:

  <plugin>
    <groupId>org.honton.chas</groupId>
    <artifactId>exists-maven-plugin</artifactId>
    <version>0.0.6</version>
    <executions>
      <execution>
        <goals>
          <goal>remote</goal>
        </goals>
      </execution>
    </executions>
  </plugin>

</plugins>

Answer 4

Очевидно, что эта потребность не решена ни Maven, ни Nexus, ни Archiva. Пока что это может быть решено только с помощью дополнительных трюков, настроенных менеджером сборки, как те, которые предлагались в предыдущих постах.

В идеальном мире

• пом будет включать
  , и версия выпуска и версия снимка модуля
  , определение файлов, которые в случае изменения оправдывают использование версии снимка
  , ссылка на систему управления исходным кодом выпущенного модуля
  

• poms зависимых модулей добавили бы в соответствующий раздел зависимостей информацию о версии выпуска рядом с информацией о версии снимка, чтобы она ссылалась на библиотеку снимков, если она присутствует в репозитории, и библиотеку релизов в противном случае
  

• реактор maven будет иметь возможность читать как иерархию зависимостей, так и информацию об изменениях файла (scm diff), чтобы узнать, будет ли данный модуль использоваться в его версии или версии моментального снимка.

• плагин релиза по умолчанию будет пропускать освобождение модулей, которые все еще могут использоваться с их версией релиза на основе изменений файла и информации о зависимостях.

Answer 5

Я хотел бы предложить, что если вы планируете поддерживать, собирать и развертывать модули независимо, вам следует рассмотреть возможность установки отдельного CI и mvn deploy рабочие места для каждого. Независимый mvn deploy работа даст вам поведение, которое вы ищете из коробки. Это означает, что не нужно использовать агрегатор pom (parentprj) для создания и развертывания этих модулей.

Если вы хотите сделать все, начиная от модуля-агрегатора, например, построить и развернуть, я бы посоветовал последовать ответу Джона и синхронизировать весь номер версии.

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

Хороший способ принять это решение - спросить себя: "Нужно ли другим проектам / приложениям ссылаться на этот модуль как на зависимость?". Если это так, то рекомендуется создать, установить и развернуть его самостоятельно. Если нет, то я не вижу никаких подводных камней для того, чтобы версии совпадали.