Вопросы Теги

Предложите хороший подход для предназначения для различных баз данных и конфигураций для dev/test/qa с Maven2?

Привет я запускаю, новый проект веб-разработки с моим использованием команды В спящем режиме и Spring MVC. Мы будем создавать с Maven2 и использовать NetBeans IDE. Наши прошлые проекты использовали муравья для системы сборки. Мы будем использовать Бамбук Atlassian для нашего сервера CI.

Мой вопрос касается лучшей практики для переключения между dev/test/qa/production средами сборки, которые имеют различные конфигурации.

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

Я пытаюсь найти, что лучший подход со Знатоком выбирает между этими средами с муравьем, которого мы просто раньше имели <copy> цели, которые скопировали бы наши конфигурационные файлы с предопределенных каталогов до сборки и переписали бы некоторых .properties файлы.

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

Я приношу извинения за свое редкое понимание Знатока, мы переключаемся на знатока, поскольку мы нашли, что разрешение зависимости удаляет огромную нагрузку для нас.

Спасибо за Вашу справку и терпение.

ОБНОВЛЕНИЕ: более простой путь, если кому-либо интересно.

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

<build>
    <resources>
        <resource>
            <!-- Needs to be here globally for common resources. -->
            <directory>src/main/resources</directory>
        </resource>
    </resources>
    ...
</build>

<profiles>
    <profile>
        <id>dev</id>
        <build>
            <resources>
                <resource>
                    <!-- will add anything here to the resources. -->
                    <directory>src/main/resource-overrides/dev</directory>
                </resource>
            </resources>
        </build>
    </profile>
    <profile>
        <id>qa</id>
        <build>
            <resources>
                <resource>
                    <directory>src/main/resource-overrides/qa</directory>
                </resource>
            </resources>
        </build>
    </profile>
    ....
</profiles>

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

<profile>
    <id>prod</id>
    <build>
        <resources>
            <resource>
                <directory>src/main/resource-overrides/prod</directory>
            </resource>
            <resource>
                <directory>src/main/resources</directory>
            </resource>
        </resources>
    </build>
</profile>
1
задан Brett Ryan 24 January 2012 в 05:27
поделиться

2 ответа

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

<profile>
 <id>test</id>
 <build>
   <plugins>
     <plugin>
       <artifactId>maven-antrun-plugin</artifactId>
       <executions>
         <execution>
           <phase>process-resources</phase>
           <goals>
             <goal>run</goal>
           </goals>
           <configuration>
             <tasks>
               <delete file="${project.build.outputDirectory}/environment.properties"/>
               <copy file="src/main/resources/environment.test.properties"
                     tofile="${project.build.outputDirectory}/environment.properties"/>
             </tasks>
           </configuration>
         </execution>
       </executions>
    </plugin>
   </plugins>
  </build>
 </profile>

Но уж точно не Maven, в лучшем случае.

1
ответ дан 2 September 2019 в 23:06
поделиться

Если ваша цель - создать разные копии jar-файла для каждого окружения, где единственное различие заключается в том, что находится в папке resources, то вы можете воспользоваться maven-resources-plugin, и заставить его скопировать ваши конфигурационные файлы из предопределенных директорий.

Для эмуляции вашей установки я создал проект, в котором есть такие файлы:

  • src/main/resources/dev/app.properties
  • src/main/resources/qa/app.properties

Моя цель - иметь в упакованном jar:

  • src/main/resources/environment/app.properties

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

Как я использовал maven-resources-plugin для достижения этой цели, добавив это в pom-файл:

<build>
    <resources>
        <resource>
            <directory>src/main/resources/${environment}</directory>
            <targetPath>src/main/reosurces/environment</targetPath>
        </resource>
    </resources>
</build>

Запустив это с помощью IDEA maven runner, установив -Denvironment=dev в VM Parameters, я получил "dev" версию файла в папке "environment", как и предполагалось.

Я бы очень рекомендовал для дальнейшего чтения взглянуть на "Better Builds with Maven". Это бесплатная электронная книга, которую вы можете найти на Maven - External Resources. Работа с ресурсами classpath рассматривается в разделе 2.6 (примечание - ссылка на этой странице не работала, когда я пробовал, но в итоге я получил электронную книгу из кэшированной версии от Google).

1
ответ дан 2 September 2019 в 23:06
поделиться
Другие вопросы по тегам:

Похожие вопросы: