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

Question

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

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

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

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

Теперь, чтобы развернуть эту структуру в 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, поскольку в версии 1.0.7 у него уже есть копия childproj2. Nexus скажет: «Ресурс, недопустимый запрос: хранилище с идентификатором =« Releases »не позволяет обновлять артефакты». Это нормально, я не хочу обновлять существующие версии по ошибке.

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

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

Answer 1

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

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

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

Answer 2

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

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

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. Пока что это может быть решено только с помощью дополнительных трюков, настроенных менеджером сборки, как те, которые предлагались в предыдущих постах.

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

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

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

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

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

Answer 5

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

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

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

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