Mi espacio

Si alguien ha decidido actualizar Maven a su versión 2.0.10 y trabaja con Microsft Windows es probable que:

${project.build.directory}/classes

en la fase de procesado de recursos se transforme en:

C:\\nivel1\\nivel2\\target/classes

Con las versiones previas, el resultado hubiera sido:

C:\nivel1\nivel2\target/classes

Y os encontréis con algunos problemas. En nuestro caso hemos tenido problemas a la hora de que hibernate encuentre las clases del dominio con sus correspondientes anotaciones que necesita procesar. Con las versiones previas no había encontrado problemas, funcionaba tanto en linux como en windows.

Si tus ingredientes son: Eclipse, Web Tool Platform (WTP), m2eclipse y un proyecto modelado con maven y con varios módulos, quizás te has encontrado con el problema de que tu aplicación web no se lanza correctamente.  Usando m2eclipse puedes importar tu proyecto maven a Eclipse creando un proyecto para cada uno de los módulos. Uno de ellos corresponderá con tu webapp, en mi caso opina-webapp.

Es probable que cuando lances tu aplicación con WTP (p.e. con Apache Tomcat) no se encuentren las librerías y salten excepciones ClassNotFound. Esto se debe a que el proyecto Eclipse que contiene tu aplicación web (webapp) no está incluyendo (en tiempo de ejecución) las librerías que tu has definido previamente como dependencias del proyecto. Para resolver esto, accedemos a las propiedades del proyecto (webapp), J2EE Modules Dependencies y seleccionados:

1. Maven Dependencies (declaradas en el POM de este módulo, más las heredadas del POM padre).
2. En mi caso además tuve que incluir:
   1. opina-model (modelo de datos)
   2. opina-dao (capa de acceso a datos)

Ahí queda esta nota por si a alguien le pasa. Supongo que si me hubiera leído documentación de m2eclipse esto no me hubiera pasado.

Supongo que con este título no estoy diciendo nada nuevo, sin embargo, el día a día nos dice otra cosa. Tan importante es desarrollar un software de calidad como su mantenimiento o explotación, de hecho, la experiencia nos dice que cuanto mejor hagamos el trabajo al principio más fácil y cómodamente abordaremos las etapas futuras.

Hablamos siempre de lo importante que es documentar, definir pruebas, refinar nuestras metodologías, definir buenas prácticas, especialización de los recursos y otras miles de cosas, pero todas ellas afectan -en gran medida- el equipo de desarrollo. ¿Y qué pasa con el resto de perfiles que interviene el ciclo de vida del software? ¿Qué pasa con los administradores de bases de datos y/o administradores de sistemas? ¿Cómo es nuestra relación con ellos? ¿Qué herramientas y procedimientos compartimos con ellos? Dentro del equipo de desarrollo hay “cosas” que comienzan a madurar y síntoma de ello es que a veces nos preguntamos, ¿Qué haríamos sin…?

En este post os hablaré concrétamente de Maven e Hibernate. En mi entorno profesional, estas dos herramientas son muy frecuentes y ambas tienen mucho que decir sobre la relación del equipo de desarrollo y el resto de perfiles que normalmente pertenecen al departamento de sistemas.

Desde hace tiempo la elaboración de libros blancos de buenas prácticas se ha convertido en una moda. En un próximo post daré mi opinión al respecto (“La parte oscura de los libros blancos”), pero por ahora sólo hago referencia porque son precisamente estos libros blancos los que indican/recomiendan/exigen el uso de herramientas como Maven e Hibernate. De qué vale que el equipo de desarrollo haga uso de este tipo de herramientas si luego nos encontramos con situaciones como estas:

• El despliegue del software lo lleva a cabo el propio departamento de sistemas y allí reina su propio libro blanco de buenas prácticas. Si nuestro proyecto está modelado con Maven, y contamos con un ecosistema software mínimamente definido, ¿Por qué tenemos que entregar un WAR con la aplicación que posteriormente descomprimen para configurar (base de datos, LDAP, SMTP, etc)? ¿Por qué los administradores de sistemas no usan Maven? Se podrían beneficiar de muchas cosas como por ejemplo los perfiles para los distintos entornos de despliegue, ejecución de pruebas que no pueden faltar y un largo etcetera. Creo que sería genial que tanto el equipo de desarrollo como el departamento de sistemas compartiesen el uso de Maven. Evidentemente, cada uno desde su perspectiva.
• ¿Por qué debemos entregar al DBA los script de creación de esquemas cuando de eso se encarga automáticamente hibernate? Recientemente preparamos para un proyecto un módulo con una interfaz de línea de comandos con varias finalidades, crear el esquema de base de datos, creación de sinónimos y carga inicial de información (tablas maestras). Con un módulo de estas características, el proceso de instalación como podéis imaginar queda resumido en ejecutar un par de sentencias desde la línea de comandos. Pues parece que esto no entraba dentro del libro blanco del departamento de sistemas.

Estos son sólo dos ejemplos que ponen de manifiesto que el equipo de desarrollo y el departamento de sistemas deben tener un único libro blanco de buenas prácticas y que existe una brecha que debe estrecharse cuanto antes.

En varias ocasiones he tenido oportunidad de charlar con responsables de departamentos de sistemas y una de sus preocupaciones es que los equipos de desarrollo les entregan software que una vez puesto en producción comienza a dar problemas. ¿Qué pasa en esta situación? Al igual que existen pruebas unitarias y funcionales, el departamento de sistemas puede disponer de pruebas de integración y sistemas que proporcionen unos indicadores para garantizar unos mínimos. No sería la primera vez que se pone en producción una aplicación con la configuración por defecto del pool C3P0 muy usado con Hibernate. Luego vienen las sorpresas. ¿Cómo comprueban los DBAs que las tablas de un sistema de información comienzan con un determinado prefijo? ¿Mirando los scripts? ¿No sería más fácil con un plugin de Maven?

Una vez más, la comunicación entre los distintos perfiles es fundamental para que el ciclo de vida de un software funcione.

Leyendo la introducción de la presentación que Brett Porter llevará a cabo en el ApacheCon US 2008, me han venido a la mente algunas situaciones que he vivido durante estos años con Apache Maven.

Si mis recuerdos no me fallan, comencé usando Maven 1 a finales del 2004 cuando decidimos usarlo en Opina. Su uso en el proyecto Opina me permitió verdaderamente conocer las bondades de esta herramienta. Por aquella época lo que más se le parecía era Apache Ant. En mi entorno profesional de entonces, lo que más predominaba era usar los IDEs para todo (definir el proyecto, compilación, empaquetado, etc.) y en contadas ocasiones, me encontraba proyectos en los que se usaba Ant. Tiempo después, y cuando mi experiencia con Maven había aumentado, impartí algunas charlas sobre esta herramienta y su beneficios en distintos escenarios.

No debemos perder de vista que los desarrolladores hacían su trabajo correctamente sin Maven ni Ant, y que por tanto, para que éstos decidieran incorporar una nueva herramienta a su día a día, algún beneficio tendrían que recibir a cambio.

Fue trabajando para el Servicio de Informática de la Consejería de Obras Públicas y Transportes (Junta de Andalucía) donde tuve la oportunidad de observar la bienvenida que los desarrolladores le hacía a Maven. He de reconocer que fue aquí donde vi por primera vez usar Maven en la Administración Pública Andaluza. Ahora las cosas han cambiado mucho, hasta tal punto, que los pliegos técnicos de los concursos públicos requieren que sus desarrollos Java usen Maven.

A continuación algunas de las situaciones con las que me he encontrado y que según en qué entornos, han podido suponer una barrera:

• La calidad y ritmo de documentación (oficial) disminuyó tras la aparición de Maven 2.x.
• La necesidad de que los ordenadores de los desarrolladores tuvieran que acceder a Internet para trabajar con los repositorios oficiales supuso un inconveniente, especialmente, en los entornos corporativos donde el acceso a Internet está controlado.
• En relación con el punto anterior, el consumo de ancho de banda. Hoy existen varias alternativas para gestionar repositorios de Maven, y como todos sabéis, uno de sus objetivos es disponer de una caché (y/o mirror) de los repositorios que más empleamos y con esto, ahorrar en ancho de banda. Por aquella época eran muy pocas las opciones en este sentido y además implicaban un nuevo frente de guerra, el responsable de sistemas (o infraestructuras) tenía que dar el visto bueno para instalar un software de este tipo.
• La mala gestión de los repositorios oficiales. ¿Cuántas veces nos hemos encontrado un artefacto en un repositorio sin su correspondiente POM? Esto se traducía en que ejecutar ciertas tareas tardaban más de lo que la paciencia de un desarrollador es capaz de aguantar estando acostumbrado a pulsar un botón y listo. Cierto, cierto, existe la opción “-O” para trabajar en modo offline. ¿Cuánto tiempo tardaste en darte cuenta de la utilidad de esta opción?
• Aunque parezca extraño, hay gente que sigue sin ver a Maven más allá de una herramienta de construcción para proyectos Java. Maven también es un framework con el podemos dar solución a necesidades específicas. Evidentemente hay gran cantidad de plugins que constituyen un valor añadido para Maven, pero es importante no perder de vista que podemos extender Maven.
• Dependencias transitivas. ¿Quién no se ha peleado con las dependencias transitivas? Hoy por hoy la situación está más controlada porque existen herramientas que nos ayudan a analizar las dependencias de nuestro proyecto. Sin embargo, todavía seguimos dependiendo de que ciertos POMs en los repositorios no estén todo lo bien que debieran y que nuestros proyectos si nos descuidamos pasen a pesar 15Mb o más.

Como en casi todo en esta profesión, siempre hay muchas maneras de hacer las cosas, pero siempre hay una que es elegante, inteligente y eficaz. Por eso os recomiendo leer estas dos referencias:

1. Maven: the definite guide
2. Better build with Maven

Supongo que me dejo cosas en el tintero, ¿Alguna aportación?

En mi anterior post comentaba que íbamos a comenzar a utilizar Doxygen para generar la documentación de nuestros fuentes. Pues bien, en esta entrada voy a comentar como ha resultado la integración de Doxygen dentro del ciclo de vida de mis proyectos.

Para integrar Doxygen con Maven he usado doxygen-maven-plugin. Este plugin básicamente lo que hace es invocar a la herramienta doxygen en la fase de generación de reportes y proporcionarle los parámetros de configuración propios de la herramienta. También existe la posibilidad de invocarlo de forma explícita.

Lo primero que necesitamos es instalar Doxygen en el equipo donde se va a construir el proyecto. En mi caso es un servidor que forma parte de nuestro ecosistema software destinado única y exclusivamente a llevar a cabo tareas de integración continua. Que no se os olvide instalar la herramienta GraphViz porque la necesitaremos para generar los gráficos de entidades y relaciones.

Una vez que tenemos estas herramientas instaladas necesitamos modificar nuestro archivo P.O.M. añadiendo el repositorio de plugins de donde se descargará el plugin que necesitamos:

<pluginRepository>
<id>doodleproject-repo</id>
<name>DoodleProject Maven 2 Repository</name>
<url>http://doodleproject.sourceforge.net/maven2/release</url>
<releases>
<enabled>true</enabled>
</releases>
</pluginRepository>

Una vez que hemos añadido el repositorio de plugins pasamos a configurar el plugin:

<plugin>
<groupId>net.sf.doodleproject</groupId>
<artifactId>doxygen-maven-plugin</artifactId>
<configuration>
<executable>${doxygenExecutable}</executable>
<configurationFile>../opina-doxygen.conf</configurationFile>
</configuration>
</plugin>

En la documentación del plugin se añade un nodo adicional justo debajo de “configuration”, sin embargo, observando el código fuente del plugin, comprobé que no era necesitario (quizás un bug). En esta configuración simplemente se le indica la ubicación del ejecutable y el archivo de configuración. Como uno de los objetivo de Maven es evitar la dependencia con los entornos de desarrollo locales, no tiene sentido haber puesto el path correspondiente a mi instalación local de Doxygen, por eso definí una variable que añadí a mi correspondiente perfil (profile.xml).

El archivo de configuración de Doxygen lo creé con el asistente gráfico que proporciona, y posteriormente lo retoqué. Algunas notas sobre el archivo de configuración:

• OUTPUT_DIRECTORY: Indicar un path relativo y correspondiente con la estructura de directorios propuesta por Maven, p.e. target/site/doxygen
• INPUT: Idem, p.e. src/main/java
• Evidentemente, lo deseable sería que estos parámetros correspondieran con ${project.reporting.outputDirectory}/doxygen y ${project.build.sourceDirectory} respectivamente. Sin embargo, para conseguir esto deberíamos aplicarle un filtro y colocarlo como un recurso.

Un inconveniente que posee este plugin es que no se integra bien con la generación del sitio web de Maven. No se genera correctamente el enlace a la documentación. En Opina para evitar este problema, hemos añadido un enlace en la menú de la izquierda. Lo tenéis publicado por si alguien quiere verlo.