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

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

7 голосов
/ 03 декабря 2008

Мы находимся в процессе преобразования нашего основного процесса сборки из муравья в maven. Мы используем TeamCity для нашего сервера непрерывной интеграции (CI).

Мы хотели бы использовать CI-сервер для запуска (ночных) сборок, версия которых содержит номер сборки, как в 1.0.0.build #. Эти сборки будут установлены в нашем локальном репозитории maven для использования в других проектах. Таким образом, сервер CI будет управлять версиями, maven будет создавать проект, а репозиторий maven сделает эти сборки доступными для других проектов.

Я намеревался начать сборку с сервера CI с помощью следующей команды: 

mvn -Dversion=1.0.0.25 install

pom проекта будет иметь фиктивный номер версии, а флаг -D переопределит его, как в: 

<version>0.0.0.0</version>

Проблема с этим методом заключается в том, что плагин установки maven использует только версию в файле pom, а не версию, переданную в командной строке. Это замечено в этой проблеме maven .

Итак, поскольку эта проблема существует с 08/2006 и не устранена, я предполагаю, что это как-то не « maven way ». Поэтому мой вопрос: как можно использовать maven в ситуации непрерывной интеграции для установки версионных артефактов в хранилище?

Ответы [ 3 ]

6 голосов
/ 03 декабря 2008

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

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

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

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

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

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

5 голосов
/ 07 сентября 2012

Ответ Мэтью предоставляет решение, при котором артефакты загружаются в локальный и удаленный репозиторий с нужным номером версии, т.е. пути внутри репозитория содержат правильные номера версий, однако 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}.

Однако вы можете использовать resol-pom-maven-plugin , который загружает POM в локальный и удаленный репозиторий, где все переменные внутри 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>
...
4 голосов
/ 08 декабря 2008

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

Используя уровень косвенности, вы можете передать номер версии 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.

...