maven-2 - mvn - maven repository local
Uso de Maven para entornos de despliegue múltiple(producción/desarrollo) (6)
Esto lo deletrea bastante bien, usa los perfiles de construcción como @seth mencionó-
http://maven.apache.org/guides/mini/guide-building-for-different-environments.html
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 creo un script Ant para crear diferentes archivos war, uno para producción y otro para desarrollo, utilizando estos comandos:
ant deploy-dev
ant deploy-prod
ant deploy-sit
ant deploy-uat
Básicamente, crean un archivo de guerra y luego actualizan el archivo de guerra insertando 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?
Intenté la mvn war pero solo crea una guerra
Hay un artículo sobre esto en maven 2 usando perfiles de compilación . 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.
He manejado esto usando Spring''s PropertyPlaceholderConfigurer e incluyendo archivos de propiedades en classpath y uno en el filesystem:
<context:property-placeholder
location="classpath*:META-INF/spring/*.properties,file:myapp*.properties"/>
Si hay un archivo myapp * .properties en el directorio actual cuando se inicia la aplicación (o se ejecutan pruebas, etc.), se anularán las propiedades de los archivos incluidos en war / ear / whatever.
La mejor práctica para tu información personal es no tener que reconstruir tu artefacto para diferentes entornos, ya que eso no conduce a la reconstrucción de construcciones capaces, y otras cosas podrían cambiar al reconstruir. Es decir, utilizando el filtrado de recursos, como se sugirió anteriormente, solo funciona al reconstruir su proyecto.
Cuando se gradúa un artefacto de desarrollo a prueba o prueba de aceptación a producción, no se debe tener que reconstruir.
Lo que quiere hacer es tener su configuración dinámica, dependiendo de las variables de tiempo de ejecución. Es decir, diferentes configuraciones de primavera o archivos de propiedades para diferentes entornos, por ejemplo:
db-dev.properties
db-test.properties
db-prod.properties
Luego puede cambiar entre estas configuraciones usando variables de tiempo de ejecución y PropertyPlaceholderConfigurer de Spring.
También puede usar diferentes archivos de configuración de primavera, como lo hice en el pasado, para configuraciones más complejas.
También sugiero que deje su configuración ''predeterminada'' como producción, de modo que si despliega en producción, no necesita preocuparse si olvida establecer la variable de entorno.
Prefiero usar perfiles maven para esta situación. Por ejemplo, tenemos estructura de directorio:
src/main/resources | +- local | | | `- specific.properties +- dev | `- specific.properties
En pom.xml define 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 necesito actualizar cada vez pom.xml para 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 esta 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>
La parte común se almacenará en src/main/resources y otras configuraciones estarán en las carpetas apropiadas en el directorio config.
Si desea eliminar 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. A continuación, parametrice el archivo de propiedades con propiedades de filtro como esta:
jdbc.url=${filtered.jdbc.property}
Luego dentro de src / main / filters crea archivos de filtro basados en perfiles. entonces podrías tener dev-filters.properties sit-filters.properties, etc. Estos contienen:
filtered.jdbc.property=jdbc url here
Luego configura los perfiles de compilación para cada región donde establece una propiedad env apunta a la región particular de su edificio. Luego 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 algunas configuraciones 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>
Además, apoyos a esta entrada de blog que es donde originalmente encontré los pasos para lograr esto.