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

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

 wonderful-inc dream-library 1.2.3  

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

ЗАМЕТКА:

Этот ответ относится только к Maven 2! Названные последние метаtagsи « LATEST и «Релиз» были отброшены в Maven 3 «ради воспроизводимых сборщиков» более 6 лет назад. Пожалуйста, обратитесь к этому решению Maven 3 .


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

Когда вы зависите от плагина или зависимости, вы можете использовать значение версии LATEST или RELEASE. LATEST относится к последней выпущенной или мгновенной версии определенного артефакта, самого недавно развернутого артефакта в конкретном репозитории. RELEASE относится к последнему выпуску, отличному от моментального снимка в репозитории. В целом, не рекомендуется разрабатывать программное обеспечение, которое зависит от неспецифической версии артефакта. Если вы разрабатываете программное обеспечение, вы можете использовать RELEASE или LATEST в качестве удобства, чтобы вам не приходилось обновлять номера версий при выпуске новой версии сторонней библиотеки. Когда вы выпускаете программное обеспечение, вы всегда должны следить за тем, чтобы ваш проект зависел от конкретных версий, чтобы уменьшить вероятность того, что ваша assembly или ваш проект пострадали от выпуска программного обеспечения, не находящегося под вашим контролем. Используйте ПОСЛЕДНИЕ и РЕЛИЗЫ с осторожностью, если вообще.

Дополнительную информацию см. В разделе Синтаксис POM книги Maven . Или посмотрите этот документ в диапазонах версий зависимостей , где:

  • Квадратная скобка ( [ & ] ) означает «закрытую» (включительно).
  • Скобка ( ( & ) ) означает «открытая» (эксклюзивная).

Вот пример, иллюстрирующий различные варианты. В репозитории Maven com.foo:my-foo имеет следующие метаданные:

  com.foo my-foo 2.0.0  1.1.1  1.0 1.0.1 1.1 1.1.1 2.0.0  20090722140000   

Если требуется зависимость от этого артефакта, у вас есть следующие параметры (конечно, можно указать другие диапазоны версий , просто показывая соответствующие здесь):

Объявите точную версию (всегда будет разрешено 1.0.1):

 [1.0.1] 

Объявите явную версию (всегда будет разрешено 1.0.1, если не произойдет столкновение, когда Maven выберет подходящую версию):

 1.0.1 

Объявить диапазон версий для всех 1.x (в настоящее время будет разрешено 1.1.1):

 [1.0.0,2.0.0) 

Объявить диапазон версий с открытым кодом (будет разрешен до 2.0.0):

 [1.0.0,) 

Объявите версию как ПОСЛЕДНЕЕ (разрешите к 2.0.0) (удалено из maven 3.x)

 LATEST 

Объявите версию как RELEASE (разрешите к 1.1.1) (удалено из maven 3.x):

 RELEASE 

Обратите внимание, что по умолчанию ваши собственные развертывания будут обновлять «последнюю» запись в метаданных Maven, но для обновления записи «release» вам необходимо активировать «профиль выпуска» из Maven super POM . Вы можете сделать это с помощью «-Prelease-profile» или «-DperformRelease = true»,


Следует подчеркнуть, что любой подход, позволяющий Maven выбирать версии зависимостей (LATEST, RELEASE и диапазон версий), может оставить вас открытым для создания проблем времени, поскольку более поздние версии могут иметь другое поведение (например, плагин зависимостей ранее переключил значение по умолчанию значение от true до false, с запутанными результатами).

Поэтому, как правило, хорошей идеей является определение точных версий в выпусках. Как указывает ответ Тима, плагин maven-versions- это удобный инструмент для обновления версий зависимостей, в частности версий: use-latest-versions и versions: use-latest-releases .

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

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

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

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

  • версии: display-dependency-updates проверяет зависимости проекта и создает отчет о тех зависимостях, которые имеют более новые версии.
  • версии: display-plugin-updates сканирует плагины проекта и создает отчет о тех плагинах, которые имеют более новые версии.
  • version : update-parent обновляет родительский раздел проекта, чтобы он ссылался на новейшую доступную версию. Например, если вы используете корпоративный POM, эта цель может быть полезна, если вам нужно убедиться, что вы используете последнюю версию корпоративного корневого POM.
  • версии: update-child-modules обновляет родительский раздел дочерних модhive проекта, чтобы версия соответствовала версии текущего проекта. Например, если у вас есть агрегатор pom, который также является родителем для проектов, которые он агрегирует, а дочерние и родительские версии выходят из синхронизации, это mojo может помочь исправить версии дочерних модhive. (Обратите внимание, что вам может потребоваться вызвать 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 «Бедняка».

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

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

 [1.2.3,) 

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

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

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

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

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

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

   org.codehaus.mojo versions-maven-plugin 1.2  com.snaphop false true   

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

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

Обновить

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

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

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

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

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

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

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

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

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

Элемент версии 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 (например, если известно, что он не работает в сочетании с этой библиотекой)

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

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

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

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

Кто когда-либо использует ПОСЛЕДНИЕ, пожалуйста, убедитесь, что у вас есть – иначе, последний снимок не будет вытащен.

 mvn -U dependency:copy -Dartifact=com.foo:my-foo:LATEST // pull the latest snapshot for my-foo from all repositories 

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

Правда даже в 3.x все еще работает, на удивление, проекты строятся и развертываются. Но ключевое слово LATEST / RELEASE вызывает проблемы в m2e и eclipse повсюду, ТАКЖЕ проекты зависят от зависимости, которая развернута через LATEST / RELEASE, неспособность распознать версию.

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

Поэтому вывод заключается в использовании версий-maven-plugin, если можно.

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

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

  1.1.1  

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

    org.codehaus.mojo versions-maven-plugin 2.3    myname.version   group-id artifact-id latest         

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

 mvn versions:update-properties validate 

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

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

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

Но как разработчик, я не буду рекомендовать этот тип практики. ЗАЧЕМ?

ответ на вопрос, почему Паскаль Тивент уже дал в комментарии к вопросу

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

Я рекомендую этот тип практики:

  3.1.2.RELEASE    org.springframework spring-core ${spring.version}   org.springframework spring-context ${spring.version}   

его легко поддерживать и легко отлаживать. Вы можете обновить свой POM в кратчайшие сроки.

  • Maven: Не удалось прочитать дескриптор артефакта
  • CMake & CTest: make test не создает тесты
  • Сложны ли зависимости круговых classов от стиля стиля кодирования?
  • Rails Engine - зависимости Gems, как загрузить их в приложение?
  • Ошибка в построении gradleа после обновления Android Studio с log4j
  • Как работает Copy-local? log4net.dll не копируется в каталог вывода MyProject
  • HintPath vs ReferencePath в Visual Studio
  • Самый простой способ установить зависимости Python от узлов-исполнителей Spark?
  • как разрешить циклическую зависимость maven
  • Android Studio - Импорт внешней библиотеки / Jar
  • Как я могу заставить проект Eclipse-Maven автоматически обновлять свой путь к classам, когда я изменяю зависимость в моем файле pom.xml?
  • Давайте будем гением компьютера.