Uso de Maven para entornos de despliegue múltiple (producción/desarrollo)

Question

Tengo una aplicación web en Maven, con la estructura de directorio predeterminada. No hay problema allí. La estructura de directorios predeterminada tiene algunos archivos de propiedades que apuntan a mi base de datos localhost.

Actualmente puedo crear un script Ant para crear diferentes archivos de guerra - uno para la producción y otro para el desarrollo, el uso de estos comandos:

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

Así que, básicamente, se crea un archivo de la guerra y luego actualizar el archivo de la guerra por conectando el archivo de propiedades

¿Hay algo así en maven (se crean diferentes guerras según la configuración)?

si es así, ¿cómo hago eso?

Traté mvn war pero simplemente crea una guerra

Answer 1

La mejor práctica FYI es no tiene que reconstruir su artefacto para diferentes entornos, ya que eso no conduce a nuevas versiones, y otras cosas podrían cambiar al reconstruir. Es decir. usar el filtrado de recursos, como se sugirió anteriormente, solo funciona cuando reconstruye su proyecto.

Cuando se gradúa un artefacto de dev a prueba o prueba de aceptación a producción - usted no necesita querer reconstruir.

Lo que se quiere hacer, es en realidad tener su configuración dinámica, en función de las variables en tiempo de ejecución. Es decir. diferentes configuraciones de resorte o archivos de propiedades para diferentes ambientes por ejemplo:

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

A continuación, se puede cambiar entre estas configuraciones utilizando las variables de tiempo de ejecución y la primavera de PropertyPlaceholderConfigurer.

Usted puede también utilizar realmente diferentes archivos de configuración de la primavera, así, como lo he hecho en el pasado, para configuraciones más complejas.

También sugiero que salga de su configuración 'por defecto' como la producción - de modo que si se implementa en la producción, que no tiene que preocuparse si se olvida de establecer la variable de entorno.

Answer 2

Hay this article sobre él en Maven 2 usando build profiles. Parece que simplemente delega a la hormiga de todos modos a través del plugin antrun, por lo que incluso podrías salirte con la suya al volver a utilizar tus archivos build.xml existentes.

Answer 3

Si desea eliminar la hormiga de su proceso, consideraría usar perfiles de compilación con filtros.

En este escenario, conecte sus archivos de propiedades a la estructura del árbol src/main/resources. Entonces parametrizar el archivo de propiedades con las propiedades del filtro como este:

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

entonces dentro de src/main/filtros crear archivos de filtro basados ​​en perfiles. lo que podría tener dev-filters.properties sit-filters.properties, etc. Estos contener:

filtered.jdbc.property=jdbc url here 

A continuación, crear perfiles de configuración para cada región en la que se establece una env propiedad que apunta a la región en particular su edificio. A continuación, puede configurar el filtro de recursos para usar ${env}-filters.properties para cada compilación. Además, puede configurar el plugin war para agregar la propiedad env a su artefacto, de modo que realmente almacene 4 artefactos diferentes en su repositorio bajo un clasificador diferente.

Luego, simplemente crea la aplicación con cada perfil. Tienes que llamar a la compilación para cada perfil, pero funciona bien.

Ejemplo de algunos ajustes en el 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> 

También, apoyos a este blog post que es donde encontré originalmente los pasos para lograr esto.

Answer 4

Esto lo explica bastante bien, utiliza los perfiles de construcción como @seth dicho-

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

Answer 5

he manejado esto utilizando PropertyPlaceholderConfigurer de primavera y que incluyen archivos de propiedades en la ruta de clase y uno en el sistema de archivos:

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

Si hay un archivo de miaplicacion * .properties en el directorio actual cuando se inicia la aplicación (o pruebas se ejecutan etc.) se anulará propiedades de los archivos de horno en la guerra/oído/lo que sea.

Answer 6

Prefiero usar perfiles maven para esta situación. por ejemplo tenemos la estructura de directorios:

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

En pom.xml definir dos perfiles:

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

En ese caso, no necesita actualizar cada pom.xml tiempo para los nuevos archivos. En IDE, simplemente cambie de perfil o use -P flag desde la línea de comando.

UPD: ¿qué hacer si algunas propiedades son las mismas para las configuraciones? Haga la configuración de la siguiente manera:

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

parte común se almacena en src/main/resources y otras configuraciones estarán en carpetas correspondientes en el directorio config.