Filtros y gestión multientorno

Cuando en Maven se habla del uso de filtros o filtrado, desde mi punto de vista, en general se está hablado de la sustitución de variables  con la forma ${nombreParametro} que solo están disponibles en tiempo de construcción. Los matices en el uso de los filtros, dependerán del lugar donde se utilicen, es decir, se puede utilizar el mecanismo de filtrado de recursos, invocando la fase que proceso los recursos o el de la fase de ensamblado, la fase build, en un plugin etc.

Vamos a ver un ejemplo

Configuración multientorno

Imaginemos que tenemos el archivo src/main/resourcesconfig/configuracion.xml y que queremos configurar los valores de un bean, en función del contenido del pom.xml y del perfil que esté activo. Lo que hacemos es indicar las propiedades de los que queremos extraer los valores con “${}“, por ejemplo:

Como se puede ver, queremos obtener una propiedad “hardcore” del pom.xml, tres propiedades que dependen del perfil activo y un par de propiedades estándar como la versión y el nombre del proyecto. El ejemplo es un poco burdo, pero ilustra muy bien el uso de los filtros y sus posibles aplicaciones.

Siguiendo con el ejemplo, vamos a suponer que hemos definido dos perfiles “entorno-desa“, y “entorno-prod“, cada uno de ellos con la se utilizará para seleccionar el fichero de propiedades de los que se tomarán los valores. Definimos en settings.xml los perfiles:

Como se puede ver, por defecto queda activado el perfil de desarrollo y la propiedad “entorno” tendrá el valor “desa”. Si se activa el perfil de producción, la variabe “entorno” valdrá “prod”.

Ahora nos vamos al pom.xml. Para que quede más claro, dejo en el pom únicamente lo que nos interesa, en una aplicación real, el pom tendrá más cosas, dependencias, plugins, etc, pero para la prueba nos vale:

Se ha definido “propiedadHardcode” con un determinado valor.

Seguidamente hemos indicado el lugar de donde queremos extraer los valores que serán sustituidos en configuracion.xml. Estarán en el paquete “src/main/filters/”, que es su lugar estándar:

Estructura de directorios Maven

Estructura de directorios Maven

Si nos fijamos, para recuperar el nombre del archivo “filtro-${entorno}.properties”, estamos usamos un filtro, es decir, se evalúa el valor de “entorno”  que como hemos dicho puede tomar el valor “desa” o “prod”. Por lo tanto, vamos a crear esos archivos de propiedades:

src/main/filters/filtro-desa.properties → que contiene:

src/main/filters/filtro-prod.properties → que contiene:

Finalmente en el pom.xml, se indican los recursos donde se aplicará el filtro. El flag “true indica que se aplicarán los filtros, si se pone a “false”, los archivos de recursos se quedan tal cual estaban.  En “” se indica los directorios donde se aplicarán los filtros, de modo que se analizarán todos los archivos del directorio en busca de cadenas de tipo “${…}” a sustituir.

Hay que tener cuidado, si en la carpeta de recursos tenemos archivos binarios, como por ejemplo imágenes ya que pueden quedar corruptos. En ese caso para evitar problemas habría que usar las opciones “” y “” de manera mutuamente excluyente. Nosotros como no tenemos imágenes, hemos usado la primera para indicar el archivo a tratar, es decir, “config/configuracion.xml“.

Bien, si generamos el War, como el perfil por defecto es el de desarrollo, endremos en “ProyectoWeb.war/WEB-INF/classes/config/configuracion.xml” lo siguiente:

Vamos a comprobar como se vería si activamos el perfil de producción. Cuando vimos los perfiles, aprendimos a activarlos por linea de comandos. Ahora vamos a ver como se realizaría en Eclipse. Vamos a “Run>>Run Configurations...”, creamos una configuración “Maven Build”, le damos un nombre, indicamos el “Base directory” del proyecto, como “Goals” introducimos “clean package” y finalmente en “Profiles” indicamos que perfil queremos que esté activo, en este caso: “entorno-prod”

Ejecutando con el perfil entorno-prod

Ejecutando con el perfil entorno-prod

Al ejecutarlo tenemos:

Como se puede ver, han cambiado las tres propiedades que dependen del perfil. Del mismo modo que en este ejemplo hemos puesto una propiedad “propiedadHardcode” en el pom.xml, se la podríamos pasar por linea de comandos, de este modo:

Aquí terminamos. En el próximo artículo hablaremos sobre los repositorios

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *