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

Возможно, вы зависите от разрабатываемых версий, которые, очевидно, сильно меняются в процессе разработки?

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

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

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

<version>[1.2.3,)</version>

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

ПРИМЕЧАНИЕ:

Упомянутые метаверсии LATEST и RELEASEбыли удалены для зависимостей плагинов в Maven 3 "ради воспроизводимых сборок", более 6 лет назад. (Они по-прежнему отлично работают с обычными зависимостями.) Информацию о зависимостях плагинов см. В этом Решение, совместимое с Maven 3.

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

When you depend on a plugin or a dependency, you can use the a version value of LATEST or RELEASE. LATEST refers to the latest released or snapshot version of a particular artifact, the most recently deployed artifact in a particular repository. RELEASE refers to the last non-snapshot release in the repository. In general, it is not a best practice to design software which depends on a non-specific version of an artifact. If you are developing software, you might want to use RELEASE or LATEST as a convenience so that you don't have to update version numbers when a new release of a third-party library is released. When you release software, you should always make sure that your project depends on specific versions to reduce the chances of your build or your project being affected by a software release not under your control. Use LATEST and RELEASE with caution, if at all.

Подробнее см. Раздел синтаксиса POM книги Maven. Или посмотрите этот документ на Диапазоны версий зависимостей, где:

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

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

<?xml version = "1.0" encoding = "UTF-8"?><metadata>
  <groupId>com.foo</groupId>
  <artifactId>my-foo</artifactId>
  <version>2.0.0</version>
  <versioning>
    <release>1.1.1</release>
    <versions>
      <version>1.0</version>
      <version>1.0.1</version>
      <version>1.1</version>
      <version>1.1.1</version>
      <version>2.0.0</version>
    </versions>
    <lastUpdated>20090722140000</lastUpdated>
  </versioning>
</metadata>

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

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

<version>[1.0.1]</version>

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

<version>1.0.1</version>

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

<version>[1.0.0,2.0.0)</version>

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

<version>[1.0.0,)</version>

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

<version>LATEST</version>

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

<version>RELEASE</version>

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

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

Поэтому обычно рекомендуется определять точные версии в выпусках. Как указывает Ответ тима, плагин версий maven - удобный инструмент для обновления версий зависимостей, особенно целей версии: используйте последние версии и версии: использовать-последние-выпуски.

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

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

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

Также предусмотрены следующие другие цели:

• версии: отображение-зависимости-обновления сканирует зависимости проекта и составляет отчет о тех зависимости, которые имеют более новые доступные версии.
• версии: дисплей-плагин-обновления сканирует плагины проекта и создает отчет об этих плагинах у которых есть более новые версии.
• версии: родитель-обновление обновляет родительский раздел проекта, поэтому что он ссылается на новейшие доступная версия. Например, если вы используете корпоративный корневой POM, это цель может быть полезной, если вам нужно убедитесь, что вы используете последнюю версию версия корпоративного root POM.
• версии: update-child-modules обновляет родительский раздел дочерние модули проекта, поэтому версия соответствует версии текущий проект. Например, если вы иметь помпон-агрегатор, который также родитель для проектов, которые он агрегаты и дети и родительские версии не синхронизируются, это mojo может помочь исправить версии дочерние модули. (Обратите внимание, что вам может потребоваться вызвать Maven с параметром -N в чтобы запустить эту цель, если ваш проект так сильно сломан, что невозможно построить из-за версии несоответствие).
• версии: блокировки-снимки ищет pom для всех -SNAPSHOT версии и заменяет их на текущая версия с отметкой времени этого -SNAPSHOT, например -20090327.172306-4
• версии: разблокировка-снимки ищет pom для всех меток времени заблокированные версии снимков и замены их с -SNAPSHOT.
• версии: диапазоны разрешения находит зависимости, используя диапазоны версий и разрешает диапазон до конкретного используемая версия.
• версии: использование-релизы ищет pom для всех версий -SNAPSHOT которые были выпущены и заменяют их с соответствующим выпуском версия.
• версии: использовать-следующие-выпуски ищет pom для всех не-SNAPSHOT версии, которые были более новыми освобождает и заменяет их следующая версия выпуска.
• версии: используйте-следующие-версии ищет пом для всех версий которые были более новой версией и заменяет их следующей версией.
• версии: совершить удаляет файлы pom.xml.versionsBackup. Формы половина встроенного "Бедного человека" СКМ ».
• версии: вернуться восстанавливает файлы pom.xml из pom.xml.versions Резервные файлы. Формы половина встроенного "Бедного человека" СКМ ».

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

В отличие от других, я думаю, что есть много причин, по которым вы можете использовать версию всегда хочу самое последнее. В частности, если вы выполняете непрерывное развертывание (у нас иногда бывает около 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>

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

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

Обновлять

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

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

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

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

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

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

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

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

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

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

Dependencies' version element define version requirements, used to compute effective dependency version. Version requirements have the following syntax:

• 1.0: "Soft" requirement on 1.0 (just a recommendation, if it matches all other ranges for the dependency)
• [1.0]: "Hard" requirement on 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 or x >= 1.2; multiple sets are comma-separated
• (,1.1),(1.1,): this excludes 1.1 (for example if it is known not to work in combination with this library)

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

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

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

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

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

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

и добавьте плагин versions-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 использовал последнюю версию зависимости, тогда вы можете использовать Плагин Versions Maven, и как использовать этот плагин, Тим уже дал хороший ответ, следуйте его отвечать.

Но как разработчик я не буду рекомендовать такой подход. ПОЧЕМУ?

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

I really don't recommend this practice (nor using version ranges) for the sake of build reproducibility. A build that starts to suddenly fail for an unknown reason is way more annoying than updating manually a version number.

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

<properties>
    <spring.version>3.1.2.RELEASE</spring.version>
</properties>

<dependencies>

    <dependency>
        <groupId>org.springframework</groupId>
        <artifactId>spring-core</artifactId>
        <version>${spring.version}</version>
    </dependency>

    <dependency>
        <groupId>org.springframework</groupId>
        <artifactId>spring-context</artifactId>
        <version>${spring.version}</version>
    </dependency>

</dependencies>

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

Мое решение в 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

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