Использование Maven для среды множественного развертывания (производство / разработка) - PullRequest
51 голосов
/ 19 июля 2009

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

В настоящее время я создаю скрипт Ant для создания различных военных файлов - один для производства и один для разработки, используя эти команды:

ant deploy-dev
ant deploy-prod
ant deploy-sit
ant deploy-uat

Таким образом, в основном они создают файл войны, а затем обновляют файл войны, подключив файл свойств

Есть ли что-то подобное в maven (разные войны создаются в зависимости от конфигурации)?

если да, то как мне это сделать?

Я пытался mvn war, но это просто создает войну

Ответы [ 7 ]

67 голосов
/ 20 июля 2009

К вашему сведению: не приходится перестраивать ваш артефакт для разных сред - так как это не приводит к повторному созданию сборок, и другие вещи могут потенциально измениться при перестроении. То есть использование фильтрации ресурсов, как предложено выше, работает только тогда, когда перестраивает ваш проект.

Когда вы переводите артефакт из dev в тест или приемочный тест в производство, вы не хотите перестраивать.

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

db-dev.properties
db-test.properties
db-prod.properties

Затем вы можете переключаться между этими конфигурациями, используя переменные времени выполнения и SpringP PropertyPlaceholderConfigurer .

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

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

62 голосов
/ 15 декабря 2011

Я предпочитаю использовать профили maven для этой ситуации. Например, у нас есть структура каталогов:

src/main/resources
|
+- local
|  |
|  `- specific.properties
+- dev
   |
   `- specific.properties

В pom.xml определите два профиля:

<profiles>
    <profile>
        <id>local</id>
        <activation>
            <activeByDefault>true</activeByDefault>
        </activation>
        <build>
            <resources>
                <resource>
                    <directory>src/main/resources/local</directory>
                </resource>
            </resources>
        </build>
    </profile>
    <profile>
        <id>dev</id>
        <build>
            <resources>
                <resource>
                    <directory>src/main/resources/dev</directory>
                </resource>
            </resources>
        </build>
    </profile>
</profiles>

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

UPD : что делать, если некоторые свойства одинаковы для конфигураций? Сделайте конфигурацию так:

<profiles>
    <profile>
        <id>local</id>
        <activation>
            <activeByDefault>true</activeByDefault>
        </activation>
        <build>
            <resources>
                <resource>
                    <directory>src/main/resources</directory>
                </resource>
                <resource>
                    <directory>src/main/config/local</directory>
                </resource>
            </resources>
        </build>
    </profile>
    <profile>
        <id>dev</id>
        <build>
            <resources>
                <resource>
                    <directory>src/main/resources</directory>
                </resource>
                <resource>
                    <directory>src/main/config/dev</directory>
                </resource>
            </resources>
        </build>
    </profile>
</profiles>

Общая часть будет сохранена в src/main/resources, а другие конфиги будут в соответствующих папках в каталоге config.

19 голосов
/ 19 июля 2009

Если вы хотите удалить ant из вашего процесса, я бы посмотрел на использование профилей сборки с фильтрами.

В этом случае подключите файлы свойств в древовидную структуру src / main / resources. Затем параметризируйте файл свойств с помощью свойств фильтра следующим образом:

jdbc.url=${filtered.jdbc.property}

Затем внутри src / main / filters создают файлы фильтров на основе профилей. чтобы вы могли иметь dev-filters.properties sit-filters.properties и т. д. Они содержат:

filtered.jdbc.property=jdbc url here

Затем вы настраиваете профили сборки для каждого региона, где вы устанавливаете свойство env, указывающее на конкретный регион вашего здания. Затем вы можете настроить фильтр ресурсов для использования ${env}-filters.properties для каждой сборки. Кроме того, вы можете настроить плагин war для добавления свойства env к вашему артефакту, чтобы вы фактически хранили 4 различных артефакта в своем хранилище под другим классификатором.

Затем вы просто создаете приложение для каждого профиля. Вы должны вызывать сборку для каждого профиля, но она работает хорошо.

Пример некоторых настроек в POM:

<build>
  <filters>
    <filter>src/main/filters/filter-${env}-application.properties</filter>
  </filters>
  <resources>
    <resource>
      <directory>src/main/resources</directory>
      <filtering>true</filtering>
    </resource>
  </resources>
  <plugins>
    <plugin>
      <artifactId>maven-war-plugin</artifactId>
      <version>2.1-beta-1</version>
      <executions>
        <execution>
          <phase>package</phase>
          <goals>
            <goal>war</goal>
          </goals>
          <configuration>
            <classifier>${env}</classifier>
          </configuration>
        </execution>
      </executions>
    </plugin>
  </plugins>
</build>

<profiles>
  <profile>
    <id>LOCAL</id>
    <activation>
      <activeByDefault>true</activeByDefault>
    </activation>
    <properties>
      <env>LOCAL</env>
    </properties>
  </profile>
  <profile>
    <id>DEV</id>
    <properties>
      <env>DEV</env>
    </properties>
  </profile>
  <profile>
    <id>UAT</id>
    <properties>
      <env>UAT</env>
    </properties>
  </profile>
  <profile>
    <id>PROD</id>
    <properties>
      <env>PROD</env>
    </properties>
  </profile>
</profiles>

Кроме того, перейдите к этому сообщению в блоге , в котором я первоначально нашел шаги для достижения этой цели.

6 голосов
/ 25 сентября 2010

Я обработал это с помощью SpringPortPlaceholderConfigurer и включил файлы свойств в classpath и один в файловой системе:

<context:property-placeholder 
    location="classpath*:META-INF/spring/*.properties,file:myapp*.properties"/>

Если в текущем каталоге есть файл myapp * .properties, когда приложение запускается (или запускаются тесты и т. Д.), Оно будет переопределять свойства из файлов, записанных в war / ear / what.

4 голосов
/ 19 июля 2009

Есть эта статья об этом на maven 2 с использованием профилей сборки . Похоже, что он просто делегирует ant в любом случае через плагин antrun, так что вы можете даже избежать повторного использования существующих файлов build.xml.

1 голос
/ 14 июля 2010

Это объясняет это довольно хорошо, использует профили сборки, как упомянуто @seth-

http://maven.apache.org/guides/mini/guide-building-for-different-environments.html

0 голосов
/ 01 июня 2019

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

https://environments -maven-plugin.sourceforge.io / index.html

Раскрытие информации. Я создал плагин.

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