Lo normal en este caso creo que sería tener un fichero de propiedades en algún sitio de la aplicación y desde el footer.jsp mostrar el valor de esa propiedad. Para que cuando generamos el war de la aplicación automaticamente en ese .properties aparezca la versión utilizada en el pom.xml nos podemos valer fácilmente de:
src/main/resources
**/*.properties
**/*.xml
**/*.xmls
**/*.sql
true
Y dentro del fichero .properties tener una propiedad que sea "version=${pom.version}".
Pero la verdad es que no lo he hecho así. Me ha dado pereza crearme un fichero de propiedades sólo para mostrar la versión.
¿Por qué no se puede hacer el filtering de los resources sobre todas las jsps? Indicándole que el
En las jsps estabamos utilizando expresiones EL, que tienen la misma nomenclatura que las variables de maven: ${...}. Y al realizar el filtering de Maven, se me estaba modificando el valor de algunas variables EL.
Debo reconocer que llegado a este punto debería haber vuelto a la idea inicial, pero siguió dándome pereza e intenté investigar otra forma de realizar sustituciones de tokens concretos y llegué a este interesante plugin: maven-replacer-plugin.
En footer.jsp puse el siguiente código:
version: PROJECT_VERSION
y en maven configuré el plugin:
com.google.code.maven-replacer-plugin
maven-replacer-plugin
1.3.2
project_version
prepare-package
replace
target/${project.artifactId}-${project.version}/WEB-INF/**/*.jsp
false
PROJECT_VERSION
${pom.version}
De esta forma le indicamos que busque en las jsps el token exacto 'PROJECT_VERSION'.
Sólo hay que tener en cuenta una cosa más para que esto funcione. en el momento en el que se ejecuta este plugin el directorio de la aplicación todavía no se encuentra en el directorio target, por lo que no se realiza bien el replace si se ejecuta la tarea 'mvn clean package'. Es necesario ejecutar 'mvn clean war:exploded package'
No hay comentarios:
Publicar un comentario