Профили Maven - dev vs production

Question

Мне было интересно, как настроить развитие против профилей maven. Должен ли я помещать репозиторий снимков в профиль dev и другие артефакты (локальное репо, для выпусков и т. Д.) В профиле производства?

Каковы основные характеристики различных профилей этих типов?

Answer 1

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

Пример профиля по умолчанию:

<profile> 
<id>default</id> 
<activation> 
<activeByDefault>true</activeByDefault> 
</activation> 
<repositories> 
    <repository> 
     <id>central</id> 
     <url>http://some_url/content/groups/public</url> 
     <snapshots> 
      <enabled>false</enabled> 
     </snapshots> 
    </repository> 
    <repository> 
     <id>snapshots</id> 
     <url>http://some_url/content/groups/public-snapshots</url> 
     <releases> 
      <enabled>false</enabled> 
     </releases> 
    </repository> 
</repositories> 

Если вы беспокоитесь о том, зависимости SNAPSHOT в ваших релизах, вы можете использовать такие инструменты, как maven-release-plugin, чтобы убедиться, что нет никаких зависимостей МГНОВЕННЫХ в вашем проекте.

Каковы основные характеристики различных профилей этих типов?

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

Другое использование, чтобы выделить определенную часть приложения, например, вы не хотите, чтобы приемо-тест подмодуль для запуска на каждом МВН теста, но только иногда при включении теста на МВН -p acceptanceTests профиль

проблемы окружающей среды конкретный строит

Теперь профили иногда используется для отдельных конфигураций, таких как соединения строки, enpoints и т.д. на моем взгляде, что не является идеальным, так как вы в конечном итоге с окружающей средой конкретных построений. Иногда этого трудно избежать, но большую часть времени это может быть решена путем экстернализации конфигурации (обязательно иметь правильное управление конфигурацией) и использовать тот же двоичный артефакт в dev/test/prod. Таким образом, вы уверены, что сборка, прошедшая системный тест, такая же, как в prod и т. Д.

Answer 2

Главное отличие, очевидно, в настройках профилей Prod, Test и Dev. Такие вещи, как

• подключения базы данных
• свойств, таких как настройки ресурсов, конфигурации потоков пула, бревенчатый местоположение файла и его размер
• параметры хранения, как для локального вы можете иметь /mnt/media но Prod, вы можете захотеть S3

различается в этих профилях.

Теперь выходим на выпуск, обычно тестовый профиль/s имеет выпуски SNAPSHOT (например, ночные сборки), которые настроены для перехода в репозиторий SNAPSHOT. И профиль Prod выпускается, как правило, с помощью Maven Release Plugin, который автоматически отключает SNAPSHOT от версии/артефактов выпуска. И настроен для хранения артефакта в репозитории RELEASES.Конфигурация для этих операций РЕПО идет как

<profile> 
     <id>test</id> 
     <distributionManagement> 
      <snapshotRepository> 
       <id>snapshotrepo</id> 
       <name>Repository for snapshots only</name> 
       <layout>default</layout> 
       <uniqueVersion>false</uniqueVersion> 
       <url>http://repo.company.com/snapshots</url> 
      </snapshotRepository> 
     </distributionManagement> 
     ..... 
     ..... 
     ..... 

    <profile> 
     <id>prod</id> 
     </distributionManagement> 
      <repository> 
       <id>releaserepo</id> 
       <name>Final release artifacts</name> 
       <layout>default</layout> 
       <uniqueVersion>false</uniqueVersion> 
       <url>http://repo.company.com/releases</url> 
      </repository> 
     </distributionManagement> 
     .... 
     .... 

верительных по этим сделкам РЕПО переходит в settings.xml.

Профиль Dev обычно не настроен на выпуск в компанию repo (поскольку он будет слишком загроможден бесполезными артефактами), он просто устанавливается в вашем локальном репо, как SNAPSHOT, и перезаписывается на каждой сборке.