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

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

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

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

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

• версии: дисплей-зависимость-обновления сканирует зависимости проекта и производит отчет о тех зависимостей, которые новее доступная версия.
• версии: дисплей-плагин-обновления сканирует Плагины проекта и создает отчет об этих плагинах которые имеют более новые версии.
• версии: update-parent обновляет Родительский раздел проекта так что он ссылался на новый имеющиеся версии. Например, если вы используете корпоративный root POM, это цель может быть полезна, если вам нужно убедитесь, что вы используете последнюю версия корпоративного корневого пом.
• версии: обновление-дочерние модули обновляет Родительский раздел дочерние модули проекта версия соответствует версии текущий проект. Например, если вы имейте агрегатор pom, который также родитель для проектов, которые он агрегаты и дети и родительские версии выходят из синхронизации, это mojo может помочь исправить версии дочерние модули. (Обратите внимание, что вам может потребоваться вызвать Maven с параметром-N в чтобы запустить эту цель, если ваш проект сломан так сильно, что это не удается построить из-за версии mis-match).
• версии: lock-snapshots поиск pom для all-SNAPSHOT версии и заменяет их текущее время версия о том, что - Снимок, например - 20090327.172306-4
• версии:разблокировка-снимки поиск pom для всех меток времени заблокированные версии snapshot и заменяет им с-снимок.
• версии: resolve-ranges находит зависимости с использованием диапазонов версий и решает ряд конкретных версия используется.
• версии: use-releases поиск POM для всех версий моментальных снимков которые были выпущены и заменены их с соответствующим освобождать версия.
• версии: use-next-releases поиск pom для всех не снимка версии, которые были более новыми отпустите и замените их на следующей версии.
• версии: используйте-next-versions поиск пом для всех версий которые были более новой версией и заменяет их следующей версией.
• версии: commit удаляет pom.XML.файлы versionsBackup. Формы одна половина встроенного - Бедняга ... СКМ."
• версии: revert восстанавливает pom.XML-файлы из ПФЛ.XML.файлы versionsBackup. Формы одна половина встроенного "бедного человека" СКМ."

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

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

<version>[1.2.3,)</version>

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

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

что я делаю, так это заставляю Hudson / Jenkins делать следующее Для каждой сборки:

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

то есть я использую плагин versions и плагин scm для обновления зависимостей, а затем проверяю его в системе управления версиями. Да, я позволяю ... CI do SCM checkins (что вам все равно нужно сделать для плагина Maven release).

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

        <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 versions глючит и в целом по своей сути несовершенен.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Так что вывод использовать версии-maven-плагин если вы можете.

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

одно решение будет использовать версии-maven-плагин. Например, можно объявить свойство:

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

и добавьте плагин versions-maven в файл 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 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

это работает для меня.

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

но как разработчик, я не буду рекомендовать этот тип практики. Почему?

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

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

Я буду рекомендовать этот тип практики:

<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 в кратчайшие сроки.