получить maven для замены значений на основе user / build.properties

Question

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

я знаю, что у maven может быть файл {userdir} /build.properties.это файл, который я хочу использовать, чтобы сохранить учетные данные БД из исходного репозитория.но я не могу заставить Мейвена выяснить, что для файла x.cfg.xml он должен заменить значения.

, поэтому у меня в одном из моих файлов hibernate.cfg.xml эта строка

<property name="hibernate.connection.url">@ssoBetaUrl@</property>

теперь, как мне заставить maven заменить эту переменную значением, которое содержится в файле {userdir} /build.properties?

edit ------------- Я играл с плагином properties-maven-plugin, но, похоже, я не смог его запустить.я помещаю это в мой родительский пом

<plugin>
                <groupId>org.codehaus.mojo</groupId>
                <artifactId>properties-maven-plugin</artifactId>
                <version>1.0-alpha-2</version>
                <executions>
                    <execution>
                        <id>read-properties</id>
                        <phase>initialize</phase>
                        <goals>
                            <goal>read-project-properties</goal>
                        </goals>
                    </execution>
                </executions>
            </plugin>

, но когда он строит, он не срабатывает.если я читаю http://maven.apache.org/maven-1.x/reference/properties.html правильно, он должен найти файл свойств сборки в папке ~ / build.properties и перейти оттуда, но я не уверен.

Answer 1

Вы можете использовать два плагина.

1. свойства-Maven-плагин

2. заменитель

   <plugin>
           <groupId>org.codehaus.mojo</groupId>
           <artifactId>properties-maven-plugin</artifactId>
           <version>1.0-alpha-1</version>
           <executions>
               <execution>
                   <phase>initialize</phase>
                   <goals>
                       <goal>read-project-properties</goal>
                   </goals>
                   <configuration>
                       <files>
                           <file>{userdir}/build.properties</file>
                       </files>
                   </configuration>
               </execution>
           </executions>
           </plugin>
   
           <plugin>
           <groupId>com.google.code.maven-replacer-plugin</groupId>
           <artifactId>replacer</artifactId>
           <version>1.5.2</version>
           <executions>
               <execution>
                   <phase>prepare-package</phase>
                   <goals>
                       <goal>replace</goal>
                   </goals>
               </execution>
           </executions>
           <configuration>
             <includes>
               <include>target/**/*.*</include>
           </includes>
               <replacements>
                   <replacement>
                       <token>@ssoBetaUrl@</token>
                       <value>http://[anyURL]</value>
                   </replacement>
               </replacements>
           </configuration>
       </plugin>
   

Answer 2

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

Как правило, мои приложения на основе гибернации будут искать файл в %user.home&/.appname/config.properties и загружать оттуда учетные данные БД и другие специфические данные развертывания. Если файл отсутствует, версия JAR по умолчанию может быть включена в JAR и скопирована в это место (при первоначальном запуске, чтобы вам не пришлось копировать и вставлять файл в новые системы), которая затем редактируется с соответствующими настройками.

Таким образом, вы можете использовать одну и ту же сборку для создания файлов JAR (или WAR) для тестовых и производственных серверов, различия будут заключаться в (предположительно уже развернутых) файлах конфигурации. Это также позволяет иметь несколько производственных развертываний, каждое из которых взаимодействует с отдельной базой данных, без каких-либо сложностей в процессе сборки.