Configuración de ambientes con Spring Framework y Maven

Un requerimiento usual en el ciclo de desarrollo de sistemas empresariales es el contar con múltiples ambientes, por ejemplo desarrollo, pruebas, pre-producción, producción.
Normalmente estos ambientes son semejantes pero no iguales y para el propósito de esta nota la diferencia importante radica en ciertas características de configuración como URLs (incluyendo direcciones IP y puertos), rutas al filesystem, etc.

Las soluciones para manejar los aspectos de configuración y facilitar la construcción de los productos a instalar pueden ser diversas: uso de archivos de propiedades y modificación manual de las mismas al momento de generar los productos, uso de diferentes scripts de construcción (para ant el build.xml o para maven el pom.xml), uso de los perfiles de maven, etc.

Otra posible solución es almacenar las propiedades de configuración en la base de datos y utilizar la clase DatabaseConfiguration de Apache Commons-Configuration para obtener estas propiedades y complementandola con el uso de perfiles de maven o variables de ambiente para determinar el ambiente.

Esta solución tiene la ventaja de que las propiedades del sistema son centralizadas, no requiere re-instalación de la aplicación cuando se necesite cambiar alguna propiedad y ayuda a proteger información sensitiva.

Métricas de software para Spring versión 2.5.1

Como un ejercicio aplique varias métricas de software al código de Spring y se presentan en un diagrama de Pirámide de acuerdo al libro Object-Oriented Metrics in Practice.
Primero que nada, tal como se menciona en la página de JDepend, un buen resultado en las métricas no indica un buen producto de software, ni tampoco un mal resultado indica un mal producto.

“… it is important to understand that “good” design quality metrics are not necessarily indicative of good designs. Likewise, “bad” design quality metrics are not necessarily indicative of bad designs. The design quality metrics produced by JDepend should not be used as yard sticks by which all designs are measured.”

No obstante, los resultados fueron muy interesantes y reveladores.

Code Organization Guidelines for Large Code Bases

En InfoQ se encuentra un video de 88 minutos de la presentación “Code Organization Guidelines for Large Code Bases” de Juergen Hoeller realizada en el SpringOne de 2006.

La presentación es bastante interesante ya que Spring es un framework de Infraestructura, es decir proporciona servicios a través de un API. Juergen comparte sus experiencias acerca de las prácticas que siguieron para mantener el API estable a través de las versiones posteriores (en 3.5 años).