java - latest - maven versions plugin




Как сообщить Maven, чтобы использовать последнюю версию зависимости? (8)

В Maven зависимости обычно настраиваются следующим образом:

<dependency>
  <groupId>wonderful-inc</groupId>
  <artifactId>dream-library</artifactId>
  <version>1.2.3</version>
</dependency>

Теперь, если вы работаете с библиотеками с частыми выпусками, постоянное обновление тега <version> может быть несколько раздражающим. Есть ли способ сказать Maven всегда использовать последнюю доступную версию (из репозитория)?


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

Что я делаю, так это сделать Хадсон / Дженкинс для каждой сборки:

mvn clean versions:use-latest-versions scm:checkin deploy -Dmessage="update versions" -DperformRelease=true

То есть я использую плагин версий и плагин scm для обновления зависимостей, а затем проверяю его на исходный элемент управления. Да, я разрешаю моим CI делать SCM-проверки (что вам нужно сделать в любом случае для плагина релиза maven).

Вы хотите настроить плагин версий только для обновления, что вы хотите:

        <plugin>
            <groupId>org.codehaus.mojo</groupId>
            <artifactId>versions-maven-plugin</artifactId>
            <version>1.2</version>
            <configuration>
                <includesList>com.snaphop</includesList>
                <generateBackupPoms>false</generateBackupPoms>
                <allowSnapshots>true</allowSnapshots>
            </configuration>
        </plugin>

Я использую плагин release для выпуска, который заботится о -SNAPSHOT и подтверждает, что существует версия -SNAPSHOT (что важно).

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

Обновить

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

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

На самом деле вам нужен отдельный инструмент от maven для настройки версий (чтобы вы не зависели от файла pom для правильной работы). Я написал такой инструмент на смиренном языке, который является Bash. Сценарий обновит версии, такие как плагин версии, и вернет обратно обратно в исходный элемент управления. Он также работает как 100x быстрее, чем плагин версий mvn. К сожалению, это не написано для публичного использования, но если люди заинтересованы, я мог бы сделать это и поставить его в суть или github.

Возвращаясь к рабочему процессу, так как некоторые комментарии спрашивали об этом, это то, что мы делаем:

  1. У нас есть около 20 проектов в их собственных хранилищах со своими собственными работами дженкинсов
  2. Когда мы выпускаем плагин релиза maven, он используется. Рабочий процесс описан в документации плагина. Плагин релиза maven отстой (и я добрый), но он работает. Однажды мы планируем заменить этот метод чем-то более оптимальным.
  3. Когда один из проектов будет выпущен, jenkins запускает специальное задание, которое мы будем называть обновлением всех версий (как известно, его выпуск является сложным, частично потому, что плагин релиза maven jenkins довольно дрянной).
  4. Обновление всех версий job знает обо всех 20 проектах. Фактически, агрегатор pom должен быть конкретным со всеми проектами в разделе модулей в порядке зависимости. Дженкинс управляет нашей магией groovy / bash foo, которая заставит все проекты обновить версии до последней версии, а затем проведет посты (снова сделанные в порядке зависимости, основанные на разделе модулей).
  5. Для каждого проекта, если pom изменился (из-за изменения версии в некоторой зависимости), он проверяется, а затем мы сразу же ping jenkins запускаем соответствующее задание для этого проекта (это должно сохранить порядок зависимости сборки, иначе вы на милость планировщика опроса SCM).

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

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

Фактически мы добавляем пользовательские XML-атрибуты через пространства имен, чтобы помочь намекнуть bash / groovy-скрипты (например, не обновлять эту версию).


Возможно, вы зависите от версий разработки, которые явно меняются во время разработки?

Вместо того, чтобы увеличивать версию версий разработки, вы можете просто использовать версию моментального снимка, которую вы перезаписываете, когда это необходимо, а это означает, что вам не придется менять тег версии при каждом незначительном изменении. Что-то вроде 1.0-SNAPSHOT ...

Но, может быть, вы пытаетесь добиться чего-то еще;)


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

Одним из способов было бы использовать maven-versions-plugin . Например, вы можете объявить свойство:

<properties>
    <myname.version>1.1.1</myname.version>
</properties>

и добавьте версии-maven-plugin в ваш файл pom:

<build>
    <plugins>
        <plugin>
            <groupId>org.codehaus.mojo</groupId>
            <artifactId>versions-maven-plugin</artifactId>
            <version>2.3</version>
            <configuration>
                <properties>
                    <property>
                        <name>myname.version</name>
                        <dependencies>
                            <dependency>
                                <groupId>group-id</groupId>
                                <artifactId>artifact-id</artifactId>
                                <version>latest</version>
                            </dependency>
                        </dependencies>
                    </property>
                </properties>
            </configuration>
        </plugin>
    </plugins>
</build>

Затем, чтобы обновить зависимость, вы должны выполнить цели:

mvn versions:update-properties validate

Если версия отличается от версии 1.1.1, она скажет вам:

[INFO] Updated ${myname.version} from 1.1.1 to 1.3.2

К тому времени, когда был поставлен этот вопрос, в maven были некоторые перегибы с диапазонами версий, но они были решены в более новых версиях maven. В этой статье очень хорошо видно, как работают диапазоны версий и лучшие практики, чтобы лучше понять, как maven понимает версии: https://docs.oracle.com/middleware/1212/core/MAVEN/maven_version.htm#MAVEN8855


МОЕ решение в maven 3.5.4, используйте nexus, в eclipse:

<dependency>
    <groupId>yilin.sheng</groupId>
    <artifactId>webspherecore</artifactId>
    <version>LATEST</version> 
</dependency>

затем в eclipse: atl + F5 и выберите force update of snapshots/release

меня устраивает.


Пожалуйста, взгляните на эту страницу (раздел «Диапазоны версий зависимостей»). То, что вы можете сделать, это нечто вроде

<version>[1.2.3,)</version>

Эти диапазоны версий реализованы в Maven2.


Синтаксис зависимостей находится в документации спецификации спецификации версии зависимостей . Вот он для полноты:

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

  • 1.0 : «Мягкое» требование 1.0 (просто рекомендация, если она соответствует всем другим диапазонам зависимости)
  • [1.0] : «Жесткое» требование 1.0
  • (,1.0] : x <= 1,0
  • [1.2,1.3] : 1.2 <= x <= 1.3
  • [1.0,2.0) : 1,0 <= x <2,0
  • [1.5,) : x> = 1,5
  • (,1.0],[1.2,) : x <= 1.0 или x> = 1.2; несколько наборов разделены запятыми
  • (,1.1),(1.1,) : это исключает 1.1 (например, если известно, что он не работает в сочетании с этой библиотекой)

В вашем случае вы можете сделать что-то вроде <version>[1.2.3,)</version>


Теперь я знаю, что эта тема устарела, но, читая вопрос и ответ на поставленный OP, кажется, что maven-versions-plugin действительно мог бы лучше ответить на его вопрос:

В частности, могут быть использованы следующие цели:

  • версии: use-latest-versions ищет pom для всех версий, которые были более новой версией и заменяли их последней версией.
  • версии: use-latest-releases ищет pom для всех версий, отличных от SNAPSHOT, которые были более новой версией и заменяют их последней версией.
  • версии: свойства обновления обновляют свойства, определенные в проекте, чтобы они соответствовали последней доступной версии определенных зависимостей. Это может быть полезно, если набор зависимостей должен быть заблокирован для одной версии.

Также предоставляются следующие цели:

  • версии: display-dependency-updates проверяет зависимости проекта и создает отчет о тех зависимостях, которые имеют более новые версии.
  • версии: display-plugin-updates сканирует плагины проекта и создает отчет о тех плагинах, которые имеют более новые версии.
  • version : update-parent обновляет родительский раздел проекта, чтобы он ссылался на новейшую доступную версию. Например, если вы используете корпоративный POM, эта цель может быть полезна, если вам нужно убедиться, что вы используете последнюю версию корпоративного корневого POM.
  • версии: update-child-modules обновляет родительский раздел дочерних модулей проекта, чтобы версия соответствовала версии текущего проекта. Например, если у вас есть агрегатор pom, который также является родителем для проектов, которые он агрегирует, а дочерние и родительские версии выходят из синхронизации, это mojo может помочь исправить версии дочерних модулей. (Обратите внимание, что вам может потребоваться вызвать Maven с опцией -N, чтобы выполнить эту задачу, если ваш проект сломан настолько плохо, что он не может построить из-за неправильного соответствия версии).
  • версии: lock-snapshots ищет pom для всех версий -SNAPSHOT и заменяет их текущей версией timestamp этого -SNAPSHOT, например -20090327.172306-4
  • версии: unlock-snapshots выполняет поиск в pom для всех снимков с моментальным снимком и заменяет их на -SNAPSHOT.
  • версии: resol- range находит зависимости с использованием диапазонов версий и разрешает диапазон для конкретной используемой версии.
  • версии: use-релизы ищет pom для всех выпусков -SNAPSHOT, которые были выпущены, и заменяет их соответствующей версией выпуска.
  • версии: use-next-releases ищет pom для всех версий, отличных от SNAPSHOT, которые были более новой версией и заменяют их следующей версией.
  • версии: use-next-versions ищет pom для всех версий, которые были более новой версией и заменяли их следующей версией.
  • версии: commit удаляет файлы pom.xml.versionsBackup. Формирует половину встроенного SCM «Бедняка».
  • version : revert восстанавливает файлы pom.xml из файлов pom.xml.versionsBackup. Формирует половину встроенного SCM «Бедняка».

Просто подумал, что я включу его для любой будущей ссылки.







maven-metadata