Как можно использовать maven в ситуации непрерывной интеграции для установки версионных артефактов в репозиторий?

Похоже, вы хотите создавать версии SNAPSHOT с уникальными версиями.

Итак, в вашем POM объявите версию как:

<version>#.#.#-SNAPSHOT</version>

Затем в разделе distributionManagement вашего POM включите уникальные версии для snapshotRepository через (см. Maven Ссылка на POM по этому поводу):

<snapshotRepository>
  <uniqueVersion>true</uniqueVersion>
  <id>your-snapshot-repo-id</id>
  <name>Your Snapshots</name>
  <url>http://your-snapshot-repo-url/maven</url>
</snapshotRepository>

К вашему сведению, обратите внимание, что соглашения Maven рекомендуют объявить версии как основные. небольшое изменение. Итак, 1.0.25 вместо 1.0.0.25. Если вы сможете использовать эту схему управления версиями, в мире Maven все будет работать более гладко.

Ответ Мэтью предоставляет решение, при котором артефакты загружаются в локальный и удаленный репозиторий с желаемым номером версии, то есть с путями внутри репозиторий содержит правильные номера версий, однако Maven всегда устанавливает и развертывает исходный файл POM, который по-прежнему будет содержать ${ciVersion} в элементе версии.

Если у вас есть многомодуль с таким общим родителем:

<project xmlns="..." xmlns:xsi="..." xsi:schemaLocation="...">
  <modelVersion>4.0.0</modelVersion>
  <parent>
    <artifactId>myParent</artifactId>
    <groupId>com.stackoverflow</groupId>
    <version>${ciVersion}</version>
  </parent>
  <artifactId>myChild</artifactId>
  ...
</project>

вы не сможете ссылаться на специальную версию модуля myChild, поскольку разрешение зависимостей будет существовать с ошибкой, что не может найти модуль myParent с версией ${ciVersion}.

Однако вы можете использовать resolve-pom-maven-plugin, который загружает POM в локальный и удаленный репозиторий, где все переменные внутри POM заменяются их фактическими значениями. Для этого вам нужно добавить следующий фрагмент в свой (родительский) POM:

...
<build>
  <plugins>
    <plugin>
      <groupId>com.sap.prd.mobile.ios.maven.plugins</groupId>
      <artifactId>resolve-pom-maven-plugin</artifactId>
      <version>1.0</version>
      <executions>
        <execution>
          <id>resolve-pom-props</id>
          <goals>
            <goal>resolve-pom-props</goal>
          </goals>
        </execution>
      </executions>
    </plugin>
  </plugins>
</build>
...

Ответ Шека, вероятно, «путь знатока», поэтому я приму его как правильный ответ. Однако мы не готовы менять наши соглашения, поэтому вот обходной путь, который мы используем.

Используя уровень косвенности, вы можете передать номер версии в pom во время сборки и использовать их при установке и развертывании плагинов. Например:

<project xmlns="..." xmlns:xsi="..." xsi:schemaLocation="...">
  <modelVersion>4.0.0</modelVersion>
  <groupId>com.stackoverflow</groupId>
  <artifactId>stackoverflow</artifactId>
  <version>${ciVersion}</version>
  <packaging>jar</packaging>
  <name>StackOverflow</name>

  <properties>
    <ciVersion>0.0.0.0</ciVersion>
  </properties>

  ...

</project>

Мы не можем напрямую переопределить $ {project.version}. Поэтому вместо этого мы добавляем второе свойство под названием «ciVersion» и присваиваем ему значение по умолчанию «0.0.0.0» в разделе свойств. Теперь сервер CI может указать номер версии, переопределив свойство ciVersion в командной строке. Как в:

mvn -DciVersion=1.0.0.25 install

Плагины установки и развертывания будут использовать значение свойства ciVersion, которое было передано при каждой ссылке на $ {project.version}, как и ожидалось, и значение по умолчанию будет использоваться, когда в командной строке не указана версия. Это позволяет нам переключиться на maven с минимальным влиянием на наш процесс. Кроме того, этот обходной путь ненавязчивый, что позволяет при желании легко переключиться на функцию SNAPSHOT.