Verwenden von Maven für mehrere Implementierungsumgebungen (Produktion/Entwicklung)

Question

Ich habe eine Web-App in Maven mit der Standardverzeichnisstruktur. Kein Problem dort. Die Standardverzeichnisstruktur enthält einige Eigenschaftendateien, die auf meine Localhost-Datenbank verweisen.

Derzeit erstelle ich einen Ant-Skript verschiedene Krieg Dateien erstellen - eines für Produktion und einen für die Entwicklung, Verwendung dieser Befehle:

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

Also im Grunde schaffen sie eine Datei Krieg und dann die WAR-Datei aktualisieren, indem Sie Einstecken der Eigenschaftendatei

Gibt es sowas in maven (je nach Konfiguration wurde ein anderer Krieg erstellt)?

wenn ja, wie mache ich das?

habe ich versucht mvn war aber es schafft nur einen Krieg

Answer 1

FYI Best Practice ist nicht müssen Sie Ihr Artefakt für verschiedene Umgebungen neu erstellen - da das nicht zu re-product-fähigen Builds führt, und andere Dinge könnten möglicherweise beim Neuaufbau ändern. I.e. Das Verwenden der Ressourcenfilterung, wie oben vorgeschlagen, funktioniert nur, wenn Ihr Projekt neu erstellt.

Wenn Sie ein Artefakt von Dev zu Test oder Abnahmetest zur Produktion absolvieren - Sie nicht wollen, um neu zu erstellen.

Was Sie tun möchten, ist Ihre Konfiguration dynamisch, abhängig von Laufzeitvariablen. I.e. unterschiedliche Federaufbauten oder Eigenschaftsdateien für verschiedene Umgebungen z:

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

Dann können Sie zwischen diesen Konfigurationen unter Verwendung einer Laufzeitvariablen und Spring PropertyPlaceholderConfigurer wechseln.

Sie können auch andere Federkonfigurationsdateien verwenden, wie in der Vergangenheit, für komplexere Setups.

Ich schlage auch vor, dass Sie Ihre 'Standard' Setup als Produktion - so, dass Sie keine Sorge haben, wenn Sie die Umgebungsvariable setzen, wenn Sie in der Produktion bereitstellen.

Answer 2

ist es this article darüber auf Maven 2 build profiles verwenden. Es sieht so aus, als würde es nur über das antrun-Plugin an die ant deligieren, so dass es Ihnen vielleicht sogar gelingt, Ihre vorhandenen build.xml-Dateien wiederzuverwenden.

Answer 3

Wenn Sie ant aus Ihrem Prozess löschen möchten, würde ich mit Build-Profilen mit Filtern aussehen.

In diesem Szenario stecken Sie Ihre Eigenschaftendateien in die Baumstruktur src/main/resources. Dann parametrieren die Eigenschaften mit Filtereigenschaften wie diese Datei:

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

dann innerhalb src/main/Filter-Filter-Dateien basierend auf Profile erstellen. so könnte man dev-filters.properties sit-filters.properties haben, usw. Diese enthalten:

filtered.jdbc.property=jdbc url here 

Dazu Setup Profile für jede Region bauen, wo Sie eine env Eigenschaft auf dem bestimmten Bereich Ihres Gebäudes zeigt. Sie können dann den Ressourcenfilter so einrichten, dass er für jeden Build verwendet. Darüber hinaus können Sie das War-Plugin so konfigurieren, dass die env-Eigenschaft zu Ihrem Artefakt hinzugefügt wird, sodass Sie tatsächlich 4 verschiedene Artefakte in Ihrem Repository unter einem anderen Klassifikator speichern.

Sie bauen dann einfach die App mit jedem Profil. Sie müssen den Build für jedes Profil aufrufen, aber es funktioniert gut.

Beispiel einiger Einstellungen im 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> 

Auch Requisiten zu diesem blog post das ist, wo ich ursprünglich die Schritte gefunden, dies zu erreichen.

Answer 4

Diese buchstabiert es ziemlich gut aus, nutzt die Build-Profile als @seth

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

Answer 5

ich dies mit PropertyPlaceholderConfigurer Frühling behandelt habe mentioned- und einschließlich Eigenschaftsdateien auf dem Classpath und eine auf dem Dateisystem:

Wenn eine Datei myapp * .properties im aktuellen Verzeichnis vorhanden ist, wenn die App gestartet wird (oder Tests ausgeführt werden usw.), überschreibt sie Eigenschaften von Dateien, die in den Krieg/Ohr/was auch immer gebacken wurden.

Answer 6

Ich bevorzuge Maven-Profile für diese Situation. Zum Beispiel haben wir Verzeichnisstruktur:

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

In pom.xml definieren zwei Profile:

<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> 

In diesem Fall ich nicht jedes Mal pom.xml für neue Dateien aktualisieren müssen. In der IDE wechseln Sie einfach Profile, oder verwenden Sie -P-Flag von der Befehlszeile.

UPD: Was tun, wenn einige Eigenschaften für Konfigurationen gleich sind? Sprechen Sie die Konfiguration wie folgt :

<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> 

Gemeinsame Teil wird in src/main/resources und andere configs gespeichert werden in entsprechenden Ordnern in config-Verzeichnis sein.