Maven: версия зависимости закрепления, в которой зависимость управляется спецификацией

Мы используем Maven BOM для управления зависимостями. из набора библиотек. Раздел DependencyManagement спецификации обычно использует диапазоны версий для указания версий этих библиотек, например, [2.0,2.1) Child pom.xml, использующие спецификацию, не указывают версии для этих управляемых зависимостей. (Редактировать для уточнения: мы используем определенные версии для сторонних зависимостей, диапазоны используются для внутренних библиотек, которые находятся в стадии разработки, где версии могут быстро меняться. Мы определяем диапазоны версий, чтобы обеспечить широкую совместимость между этими библиотеками, т. е. все в пределах одного и того же основная версия.)

(Обратите внимание, что это не многомодульный проект. Библиотеки и сервисные проекты, использующие механизм BOM, просто объявляют его родительским и извлекают из репозитория Nexus. Они не собираются вместе.)

У нас также есть несколько системных скриптов сборки, которые используют versions:resolve-ranges. для закрепления версий зависимостей, появляющихся в нашей библиотеке и службе pom.xml (не pom.xml спецификации). Эти pom.xml с разрешенными диапазонами регистрируются в системе управления версиями и помечаются тегами, так что, если нам нужно откатить развертывание до более ранней версии, мы можем использовать этот помеченный pom.xml для создания сборки, использующей те же версии зависимостей, что и исходная сборка, даже если теперь доступна более новая версия зависимости (и, таким образом, resolve-ranges выдаст более новую версию, если мы перезапустим ее).

Я только что заметил, что эти два механизма плохо работают вместе. Запуск versions:resolve-ranges в библиотеке или службе pom.xml разрешает только диапазоны в этом pom.xml. Версии, находящиеся под управлением зависимостей, по-прежнему не указаны, поэтому, если мы создадим новую сборку с использованием этого pom.xml, мы получим последнюю версию зависимостей в диапазоне во время сборки. Не то, что мы хотим!

Есть ли способ использовать versions:resolve-ranges (или любой другой подключаемый модуль или метод) для разрешения управляемых версий и вставки их в дочерний файл pom.xml?

Вот надуманный пример.

Спецификация:

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
    <modelVersion>4.0.0</modelVersion>
    <groupId>com.maventest</groupId>
    <artifactId>myproject</artifactId>
    <packaging>pom</packaging>
    <version>1.0-SNAPSHOT</version>
    <name>myproject</name>
    <url>http://maven.apache.org</url>
    <dependencyManagement>
       <dependencies>
          <dependency>
             <groupId>commons-lang</groupId>
             <artifactId>commons-lang</artifactId>
             <version>[2.0, 2.3]</version>
          </dependency>
       </dependencies>
    </dependencyManagement>
</project>

Дочерний проект с использованием спецификации (одна управляемая зависимость, одна неуправляемая):

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
  <parent>
    <groupId>com.maventest</groupId>
    <artifactId>myproject</artifactId>
    <version>1.0-SNAPSHOT</version>
    <relativePath>../myproject/pom.xml</relativePath>
  </parent>
  <modelVersion>4.0.0</modelVersion>
  <groupId>com.maventest</groupId>
  <artifactId>mytest</artifactId>
  <packaging>jar</packaging>
  <version>1.0-SNAPSHOT</version>
  <name>mytest</name>
  <url>http://maven.apache.org</url>
  <dependencies>
    <dependency>
      <groupId>commons-lang</groupId>
      <artifactId>commons-lang</artifactId>
      <scope>compile</scope>
   </dependency>
   <dependency>
     <groupId>junit</groupId>
     <artifactId>junit</artifactId>
     <version>[3.8, 3.9)</version>
     <scope>test</scope>
   </dependency>
  </dependencies>
</project>

Фрагмент из mvn dependency:tree, показывающий эффективные версии зависимостей:

[ИНФОРМАЦИЯ] com.maventest:mytest:jar:1.0-SNAPSHOT

[INFO] +- commons-lang:commons-lang:jar:2.3:compile

[INFO] \- junit:junit:jar:3.8.2-brew:test

Раздел зависимостей из mytest pom.xml после mvn versions:resolve-ranges:

<dependencies>
  <dependency>
    <groupId>commons-lang</groupId>
    <artifactId>commons-lang</artifactId>
    <scope>compile</scope>
  </dependency>
  <dependency>
    <groupId>junit</groupId>
    <artifactId>junit</artifactId>
    <version>3.8.2-brew</version>
    <scope>test</scope>
  </dependency>
</dependencies>

Таким образом, неуправляемая зависимость разрешается, как и ожидалось. А вот управляемый - нет. Как я могу решить это тоже?


person ryryguy    schedule 19.10.2017    source источник
comment
Спецификация не должна использовать диапазоны версий. Лучше определить конкретные версии используемых библиотек... и вам не нужно менять версии в дочернем...   -  person khmarbaise    schedule 20.10.2017
comment
Спецификация использует определенные версии для сторонних материалов. Мы используем диапазоны версий для наших внутренних библиотек, находящихся в стадии разработки, где версии могут меняться очень быстро. Было бы непрактично использовать для них определенные версии. (При этом, возможно, дело в том, что нам просто не следует обеспечивать управление зависимостями для этих библиотек в спецификации и явно указывать диапазоны в дочерних элементах.)   -  person ryryguy    schedule 20.10.2017
comment
Вы можете обновить зависимости через версии-maven-plugin, которые также могут обрабатываться автоматическими процессами, поэтому нет необходимости делать это вручную. Кроме того, диапазоны версий делают вашу сборку невоспроизводимой...   -  person khmarbaise    schedule 20.10.2017
comment
Да, мы используем version-maven-plugin для автоматического разрешения диапазонов в Jenkins, чтобы создать версию pom, которую можно использовать для воспроизведения сборки, и это сборки, которые мы развертываем. Диапазоны по-прежнему очень полезны для нас, выполняющих параллельную итеративную разработку, создание локальных сборок моментальных снимков и т. д., когда мы не заботимся о воспроизводимости сборки. Это хорошо работало для нас до того, как мы представили спецификацию; единственная проблема в том, что эта система не работает с диапазонами в спецификации.   -  person ryryguy    schedule 20.10.2017


Ответы (1)


Забыли об этом вопросе! В конце концов, я так и не смог найти способ закрепить управляемые версии, основанные на диапазонах. Поэтому я перестал определять версии в спецификации и просто указал их диапазоны в каждом дочернем элементе pom. Больше шаблонов в детских помпонах, но не так уж и плохо.

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

person ryryguy    schedule 24.09.2019