Версии проекта Maven 2, версии зависимостей и вечный выпуск

Question

Сценарий: система имеет ряд компонентов, каждый из которых имеет собственное POM. Существуют длинные цепочки зависимостей (A зависит от B, зависит от C и т. Д.). Я хочу, чтобы каждая сборка «не для разработчиков на рабочем столе» была потенциальным кандидатом на выпуск - если она пройдет QA, мы развернем ее без перестройки. Другими словами, я никогда не хочу создавать версии SNAPSHOT как часть моих регулярно запланированных сборок, только версии вроде 1.3.0.5, 1.3.0.6 и т. Д. Я также хочу позволить разработчикам работать сразу с несколькими компонентами.

Чтобы избежать некоторых ожидаемых предложений: плагин Maven Release не поможет мне ... если только не найдется какой-то волшебный способ, чтобы мои версии зависимостей не были SNAPSHOT в POM, но все же позволяли разработчикам работать над несколькими компонентами в один раз?

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

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

Допустим, у меня есть компоненты util, libj, libk, APP и UI с такими зависимостями:

libj -> util (libj зависит от util)

libk -> util

APP -> libj

Пользовательский интерфейс -> libj, libk

У меня есть команды разработчиков, работающие над APP и пользовательским интерфейсом, и им иногда нужно будет вносить изменения / дополнения в некоторые зависимости (даже в util), чтобы включить их текущую работу. Как должны выглядеть проверенные версии POM и зависимостей для каждого компонента?

Редактировать: я обновил заголовок, ссылаясь на Maven 2 вместо 2.0, поскольку стало очевидно, что мне нужно будет работать с версией 2.1 или выше, чтобы лучше решить эту проблему.

Answer 1

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

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

Мне также полезно сохранять версии внешних зависимостей, указанные в качестве свойств, в верхней части моего проекта. Это позволяет сразу увидеть, что нужно выпустить. Посмотрите на пример Nexus pom.

Answer 2

Это то, что я нахожу очень сложным с maven и внутренними проектами; у вас есть две системы управления версиями (maven, что, прямо скажем, не очень хорошо) и система контроля исходного кода (которая, предполагая, что она CVS или лучше, поддерживает реальный рабочий процесс).

Вот как мы это делаем:

report --depends on--> core
web    --depends on--> core

Мы используем заглушку Maven:

Отчет POM, в процессе разработки, будет иметь версию SNAPSHOT, соответствующую тому, что находится в ядре ядра. Я делаю mvn clean install в ядре, затем я вижу эти изменения в report в моей локальной среде.

Когда я делаю релиз отчета, я должен сначала выпустить ядро ​​через плагин релиза maven. Когда я использую его на ядре, он просит меня установить версию ядра для выпуска (то есть удалить -SNAPSHOT), на что я говорю да, и полученный выпущенный артефакт не зависит от выпуска SNAPSHOT. Когда плагин релиза завершен, pom отчета теперь зависит от следующего выпуска ядра SNAPSHOT (хотя вы можете переопределить это во время mvn release:prepare, если хотите).

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

Answer 3

мы работаем с «Super Parent» .pom-проектом, в котором версии определены как свойства, а в каждом child.project версии устанавливаются с этими свойствами

Кроме того, реальные проекты не имеют установленной версии, вместо этого они наследуют ее от своего родительского pom-проекта (включая groupId и т.

с этой настройкой версии определяются только в некоторых родительских pom-проектах, поэтому необходимая настройка минимизируется

например. эта структура

• супер родительский pom-проект (все сторонние версии определены как свойства, например 2.5.6 spring-framework) ---- pom-проект постоянства-родителя, наследует все от супер-родителя ------ JAR-проект persistence-foobar, наследует все от persistence-parent ---- util-parent

и т.д.

только версии, которые вы видите, находятся внутри родительских отношений Пример:

        <modelVersion>4.0.0</modelVersion>
<artifactId>foo-bar-foo</artifactId>
<packaging>jar</packaging>
<name>whatever</name>
<description>...</description>
<parent>
    <groupId>org.foo.bar</groupId>
    <artifactId>persistence-parent</artifactId>
    <version>1.0-SNAPSHOT</version>
</parent>
<dependencies>
    <dependency>
        <groupId>${project.groupId}</groupId>
        <artifactId>foo-bar</artifactId>
        <version>${project.version}</version>
    </dependency>
    <dependency>
        <groupId>${project.groupId}</groupId>
        <artifactId>foo-bar</artifactId>
        <version>${project.version}</version>
        <scope>test</scope>
    </dependency>
    <dependency>
        <groupId>org.springframework</groupId>
        <artifactId>org.springframework.jdbc</artifactId>
        <version>${parent.spring.version}</version>
    </dependency>

это работает так, потому что внутри pom вы можете использовать уже определенные значения, такие как версия, даже если версия установлена ​​через наследование

мы объединяем это с настройками модуля в родительских проектах, чтобы упростить сборку

Answer 4

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

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