Выпустить разные конфигурации с Maven

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

Каждый выпуск помечен как SVN, а также загружен в наш внутренний репозиторий Nexus. Я хочу иметь возможность взять определенный выпуск и реконструировать его на основе профиля. Есть ли способ сделать что-то подобное? Я должен использовать что-то кроме профилей?


person samblake    schedule 05.10.2010    source источник
comment
Вы можете уточнить последний абзац? Что вам нужно, чего у вас сейчас нет?   -  person Pascal Thivent    schedule 06.10.2010
comment
Итак, в основном, наряду со стандартным выпуском в нашем внутреннем репозитории, мне нужен выпуск для каждого клиента. В настоящее время у нас есть myProject.war. Мне также нужны myProject-custA.war и myProject-custB.war. Я могу определить каждый клиентский проект с помощью профилей, но я не знаю, есть ли способ опубликовать их в репозитории. Или, по крайней мере, способ в Maven автоматически создавать артефакт с указанным профилем, скажем, из тега SVN.   -  person samblake    schedule 06.10.2010
comment
В итоге я сделал что-то немного другое. Мы не храним выпуски в нашем внутреннем репозитории. Вместо этого мы строим с использованием Hudson и проекта с несколькими конфигурациями (одна конфигурация / профиль для каждого клиента). Таким образом, при выпуске релиза запускается задание Hudson для создания различных войн для всех клиентов. Затем они хранятся на сервере Hudson вместо Nexus. Сборки для определенных версий и клиентов также могут быть созданы в любое время из выпусков в Nexus.   -  person samblake    schedule 16.03.2011


Ответы (4)


«объявить несколько запусков для плагина войны, чтобы произвести несколько артефактов (и установить / развернуть их)» Похоже, это может быть шагом вперед. Как бы я это сделал?

Это немного противоречит золотому правилу Maven (правило одного главного артефакта на модуль), но это можно сделать. Один артефакт с несколькими конфигурациями в Maven в блоге описан один из способов реализации этого подхода:

Я решил поместить всю конфигурацию среды в специальное дерево исходных текстов со следующей структурой:

+-src/
  +-env/
    +-dev/
    +-test/
    +-prod/

Затем я настроил maven-war-plugin на три разных исполнения (по умолчанию плюс два дополнительных), по одному для каждой среды, создавая три разных файла war: beer-1.0-dev.war, beer-1.0-test.war и beer -1.0-prod.war. Каждая из этих конфигураций использовала стандартные файлы вывода из проекта, а затем копировала содержимое из соответствующего каталога src/env/ в файлы вывода, позволяя поместить файл переопределения в соответствующий каталог src/env/. Он также поддерживает копирование полной древовидной структуры в выходной каталог. Таким образом, если вы, например, хотели заменить web.xml в тесте, вы просто создали следующий каталог:

src/env/test/WEB-INF/

и поместили свой тестовый web.xml в этот каталог, и если вы хотите переопределить файл db.property, помещенный в корневой каталог пути к классам для тестовой среды, вы создали следующий каталог:

src/env/test/WEB-INF/classes

и поместил свой тестовый db.property файл в этот каталог.

Я сохранил каталог src/main, настроенный для среды разработки. Причиной этого была возможность использовать maven-jetty-plugin без какой-либо дополнительной настройки. Конфигурация

Ниже вы найдете конфигурацию maven-war-plugin, которую я использовал для этого:

<plugin>
  <artifactId>maven-war-plugin</artifactId>
  <configuration>
    <classifier>prod</classifier>
    <webappDirectory>${project.build.directory}/${project.build.finalName}-prod</webappDirectory>
    <webResources>
      <resource>
        <directory>src/env/prod</directory>
      </resource>
    </webResources>
  </configuration>
  <executions>
    <execution>
      <id>package-test</id>
      <phase>package</phase>
      <configuration>
        <classifier>test</classifier>
        <webappDirectory>${project.build.directory}/${project.build.finalName}-test</webappDirectory>
        <webResources>
          <resource>
            <directory>src/env/test</directory>
          </resource>
        </webResources>
      </configuration>
      <goals>
        <goal>war</goal>
      </goals>
    </execution>
    <execution>
      <id>package-dev</id>
      <phase>package</phase>
      <configuration>
        <classifier>dev</classifier>
        <webappDirectory>${project.build.directory}/${project.build.finalName}-dev</webappDirectory>
        <webResources>
          <resource>
            <directory>src/env/dev</directory>
          </resource>
        </webResources>
      </configuration>
      <goals>
        <goal>war</goal>
      </goals>
    </execution>
  </executions>
</plugin>

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

У вас есть несколько вариантов:

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

Или, по крайней мере, способ в Maven автоматически создавать артефакт с указанным профилем, скажем, из тега SVN.

Что ж, это выполнимо. Но без более подробной информации о конкретной проблеме трудно быть более точным.

person Pascal Thivent    schedule 06.10.2010
comment
объявить несколько запусков для плагина war для создания нескольких артефактов (и установить / развернуть их). Похоже, это может быть шагом вперед. Как бы я это сделал? - person samblake; 06.10.2010
comment
Это решение работает для меня в maven-war-plugin v3.0.0. Единственным недостатком (в моем тесте) является то, что он дублирует десятки мегабайт файлов jar в нескольких файлах war, чтобы представить различия в файлах конфигурации, составляющие всего десятки байтов. - person chrisinmtown; 17.03.2017

Я бы посмотрел на вашу архитектуру и посмотрел, есть ли способ разделить ваш проект на несколько проектов. Один будет основной кодовой базой. Другие проекты будут зависеть от файла JAR, созданного основным проектом, и добавлять их собственную конфигурацию, зависимости и т. Д. Для создания вашего окончательного артефакта.

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

person David    schedule 05.10.2010

Вы ознакомились с подключаемым модулем Maven Assembly?

Этот плагин позволяет вам настроить способ сборки вашего дистрибутива, то есть какой формат (.tar.gz, .zip и т. Д.), Структуру каталогов и т. Д. Я думаю, вы должны иметь возможность привязать несколько экземпляров плагина к фазе package, чтобы собрать несколько вариантов ваша продукция (т. е. упаковка для клиента 1, клиента 2 и т. д. отдельно).

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

person matt b    schedule 05.10.2010

В итоге я сделал что-то немного другое. Мы не храним выпуски в нашем внутреннем репозитории. Вместо этого мы строим с использованием Hudson и проекта с несколькими конфигурациями (одна конфигурация / профиль для каждого клиента). Таким образом, при выпуске релиза запускается задание Hudson для создания различных войн для всех клиентов. Затем они хранятся на сервере Hudson вместо Nexus. Сборки для определенных версий и клиентов также могут быть созданы в любое время из выпусков в Nexus. - samblake 16 марта '11 в 12:32

person samblake    schedule 10.10.2012