Как настроить версию maven-site-plugin по умолчанию для всего проекта? [Дубликат]

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

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

Update

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

<version>[1.2.3,)</version>

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

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

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

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

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

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

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

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

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

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