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
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 spring 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 spring, 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:
local true src/main/resources/local dev src/main/resources/dev
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:
local true src/main/resources src/main/config/local dev src/main/resources src/main/config/dev
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 ant de su proceso, consideraría usar perfiles de comstackció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 comstackció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 comstackció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 repository bajo un clasificador diferente.
Luego, simplemente crea la aplicación con cada perfil. Tienes que llamar a la comstackción para cada perfil, pero funciona bien.
Ejemplo de algunas configuraciones en el POM:
src/main/filters/filter-${env}-application.properties src/main/resources true maven-war-plugin 2.1-beta-1 package war ${env} LOCAL true LOCAL DEV DEV UAT UAT PROD PROD
Además, apoyos a esta entrada de blog que es donde originalmente encontré los pasos para lograr esto.
He manejado esto usando Spring’s PropertyPlaceholderConfigurer e incluyendo archivos de propiedades en classpath y uno en el filesystem:
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.
Hay un artículo sobre esto en maven 2 usando perfiles de comstackción . Parece que simplemente delega a la ant 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.
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