Ya hablaba de esto hace algún tiempo, y después de varios meses de trabajo hemos publicado la primera versión (0.1) de Sonar PDF Plugin.

En esta primera versión se ha optado por envolver la lógica de generación del reporte en un plugin para Maven, el cual está disponible en el repositorio central de Maven.

El reporte actual contiene:

• Información general del proyecto (nombre, descripción, version, módulos)
• Dashboard (indicadores proporcionados por Sonar, similar al dashboard que muestra Sonar en su interfaz web)
• Violaciones de reglas por categorías
• Reglas más violadas
• Ficheros que más violan las reglas
• Todo lo anterior para cada módulo que compone el proyecto (si existe alguno)

Ya hay algunas mejoras reflejadas en JIRA para la versión 0.2, seguiremos trabajando.

Seguro que todos nos hemos encontrado con ciertas peculiaridades de las herramientas que usamos día a día, pero encontrarse con dos (de las buenas) en un solo día, eso no tiene precio ;) sobre todo cuando el tema te quita medio día.

Son sólo detalles, pero si se dan las condiciones precisas… puede ser un quebradero de cabeza.

Cuando hay dos clases con el mismo FQN (Fully Qualified Name) en el classpath, ¿cuál de las dos se carga? Pues la respuesta es que depende, con Java 1.5 puede ser una, y con Java 1.6 puede ser otra. Resulta que tenía en mi classpath tres versiones de commons-collections (fruto de descontrol con las dependencias transitivas). Si ejecutaba los tests con Java 1.5 todo iba bien, se estaba usando commons-collections-3.1 (que era la versión que yo tanía en mi POM). Pero si usaba Java 1.6 resulta que se cargaba commons-collections-2.1.1 y uno de los métodos que se llamaba por reflexión no existía en esta versión pero sí en la 3.1. La solución, estudiar de donde viene esa dependencia transitiva y excluirla en el POM para que no haya diferentes versiones de un mismo artefacto.

¿Por qué no me aparecen los enlaces a los módulos hijos en el Maven Site? Mi proyecto tenía la estructura típica de un proyecto Maven multimódulo. Configuré los ficheros site.xml para que en el Maven site se pueda navegar mediante enlaces desde el proyecto padre a los hijos y viceversa. Resulta que los enlaces no aparecen. El problema resultó ser que en los POM de los módulos hijos tenía una etiqueta <url> y su contenido era el mismo que en el POM padre, quitando este nodo en los POM de los hijos… problema resuelto. Cuanto menos, curioso.

En fin, el primero de los problemas lo detecté rápido mirando las dependencias transitivas de mi proyecto con Q4E. El segundo fué más bien suerte y gracias alguna incidencia en Codehaus que hablaba de la influencia en el site de la etiqueta <url>.

¿Es posible aislar todo el código javascript de nuestra aplicación web en un proyecto a parte?

Si, lo es. Con javascript-maven-tools, en concreto con javascript-maven-plugin. Este plugin nos permite tratar con proyectos de tipo javascript, es decir, esto sería válido:

...
<dependencies>
    ...
    <dependency>
        <gruopId>example.javascript</groupId>
        <artifactId>my-javascript</artifactId>
        <version>1.0.0</version>
        <type>javascript</type>
    </dependency>
    ...
</dependencies>
...

Este plugin habilita el uso del tipo “javascript” en nuestras dependencias. Sólo debemos configurarlo:

<build>
    <plugin>
        <groupId>org.codehaus.mojo.javascript</groupId>
        <artifactId>javascript-maven-plugin</artifactId>
        <version>1.0-alpha-1-SNAPSHOT</version>
        <extensions>true</extensions>
        <executions>
            <execution>
                <id>js-copy-deps</id>
                <goals>
                    <goal>war-package</goal>
                </goals>
                <phase>package</phase>
            </execution>
        </executions>
    </plugin>
</build>

¿Y el artefacto javascript, cómo se crea?

Pues definiendo un proyecto maven de tipo “javascript”. Es decir, el “packaging” será de tipo “javascript” en el POM:

<packaging>javascript</packaging>

Y definiremos la siguiente extensión:

...
<build>
    <extensions>
        <extension>
            <groupId>org.codehaus.mojo.javascript</groupId>
            <artifactId>javascript-maven-plugin</artifactId>
            <version>1.0-alpha-1-SNAPSHOT</version>
         </extension>
    </extensions>
    <plugins>
        <plugin>
            <groupId>org.codehaus.mojo.javascript</groupId>
            <artifactId>javascript-maven-plugin</artifactId>
            <version>1.0-alpha-1-SNAPSHOT</version>
            <extensions>true</extensions>
         </plugin>
     </plugins>
</build>
...

Maven tratará nuestro proyecto como un projecto más, y tenemos a nuestra disposición toda la potencia de la gestión de dependencias de Maven.

Para configurar el comportamiento del plugin debemos indicarle un proporcionar un par de parámetros, basta con incluir las propiedades en el POM:

<properties>
    <scripts>public/scripts</scripts>
    <lib></lib>
    <useArtifactId>true</useArtifactId>
</properties>

Eso es todo. Solo un detalle más, el plugin tiene algunos bugs, he reportado un parche a sus desarrolladores, aún no lo han incluido en la versión actual. Siempre podemos descargar el código y parchearlo nosotros mismos ;)

Uno de los usos más típicos del plugin Assembly de Maven es la generación de un “distribuible” de nuestro proyecto. Mediante el uso de este plugin podemos seleccionar qué partes del proyecto se incluirán en el “distribuible”.

También podemos, por ejemplo, generar una distribución de código fuente del proyecto que no contenga datos relativos a nuestro entorno y sea “compilable” fuera de él.

Pero en realidad lo que podemos conseguir con este plugin es ilimitado, pudiendo definir “transformaciones” de todo tipo:

Objetivo: modelar el ciclo de vida de un módulo de OpenCMS con Maven2

Si realizamos una búsqueda rápida en google vemos que las palabras OpenCMS y Maven no aparecen juntas facilmente. La única referencia interesante es el plugin desarrollado por Comundus, pero está orientado a la gestión del proyecto OpenCMS completo, no al desarrollo de módulos de forma aislada. En este post veremos cómo gestionar dependencias, compilar y empaquetar un módulo de OpenCMS con Maven2.

En el proceso de modelado hay una restricción: el código fuente debe ser compatible con el uso del plugin opencmsmoddev para Eclipse. Esto nos obliga a no seguir la estructura típica de un proyecto Maven sino la que requiere dicho plugin. La estructura requerida es la siguiente:

--+ src
--+ system
  |--+ workplace
     |--+ resources
--+ lib
--+ schemas
--+ templates
--+ manifest.xml
--+ pom.xml

Dada esta premisa, necesitamos configurar el P.O.M de una forma un poco especial. En primer lugar debemos indicar donde estan nuestros fuentes y donde poner los compilados:

<sourceDirectory>src</sourceDirectory>
<outputDirectory>classes</outputDirectory>

Además el resultado de realizar un mvn package debe ser un zip desplegable en una instancia de OpenCMS. Para ello utilizaremos el plugin maven-antrun-plugin con la siguiente configuración:

<plugin>
    <artifactId>maven-antrun-plugin</artifactId>
    <version>1.1</version>
    <executions>
        <execution>
            <id>zip-module</id>
            <goals>
                <goal>run</goal>
            </goals>
            <phase>package</phase>
            <inherited>false</inherited>
            <configuration>
                <tasks>
                    <echo>Packaging OpenCMS Module...</echo>
                    <mkdir dir="target/dist/system/modules/${project.groupId}.${project.artifactId}" />
                    <copy todir="target/dist/system/modules/${project.groupId}.${project.artifactId}/src">
                        <fileset dir="src" />
                    </copy>
                    <copy todir="target/dist/system/modules/${project.groupId}.${project.artifactId}/classes">
                        <fileset dir="classes" />
                    </copy>
                    <copy todir="target/dist/system/modules/${project.groupId}.${project.artifactId}/schemas">
                        <fileset dir="schemas" />
                    </copy>
                    <copy todir="target/dist/system/modules/${project.groupId}.${project.artifactId}/templates">
                        <fileset dir="templates" />
                    </copy>
                    <copy todir="target/dist/system/workplace">
                        <fileset dir="system/workplace" />
                    </copy>
                    <copy file="manifest.xml" todir="target/dist" />
                    <zip destfile="target/${project.groupId}.${project.artifactId}.zip" basedir="target/dist" />
                </tasks>
            </configuration>
        </execution>
    </executions>
</plugin>

Esta tarea genera el zip requerido por OpenCMS a partir de lo que anteriormente hemos puesto en target/dist.

Aprovecharemos la gestión de dependencias que nos ofrece Maven, en principio la única dependencia que necesitamos es la del propio núcleo de OpenCMS. He usado como base OpenCMS 7.0.5, no he encontrado esta dependencia en ningún repositorio de Maven (conocido). Para solventar esto debemos instalarla en nuestro repositorio local e incluir la dependencia correspondiente en el P.O.M:

<dependency>
    <groupId>org.opencms</groupId>
    <artifactId>opencms</artifactId>
    <version>7.0.5</version>
    <scope>provided</scope>
</dependency>

La marcamos como provided ya que en tiempo de ejecución será OpenCMS el que la incluya en el classpath.

OpenCMS requiere que ciertos recursos se coloquen en el directorio src junto a los fuentes, para poder usar filtrado usaremos:

<resources>
    <resource>
        <directory>src</directory>
        <filtering>false</filtering>
        <excludes>
            <exclude>**/*.java</exclude>
        </excludes>
    </resource>
</resources>

Al empaquetar el módulo necesitamos incluir todas sus dependencias (excepto la marcadas con scope provided), para ello usaremos maven-dependency-plugin:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-dependency-plugin</artifactId>
    <executions>
        <execution>
            <id>copy</id>
            <phase>process-resources</phase>
            <goals>
                <goal>copy-dependencies</goal>
            </goals>
            <configuration>
                <excludeScope>provided</excludeScope>
                <outputDirectory>target/dist/system/modules/${project.groupId}.${project.artifactId}/lib</outputDirectory>
                <overWriteReleases>true</overWriteReleases>
                <overWriteSnapshots>true</overWriteSnapshots>
            </configuration>
        </execution>
    </executions>
</plugin>

Este es el fichero pom.xml completo.

Si no cuidamos las dependencias transitivas de nuestros proyectos web modelados con Maven, podemos encontrarnos con el problema de que nuestro WAR alcance un tamaño desproporcionado (hablamos de 40 o 50 MB), evidentemente, esto no es lógico. Está claro que estamos incluyendo decenas de librerías que no son usadas.

En los últimos días he estado llevando a cabo la tarea de “limpiar” las dependencias de uno de los proyectos en los que estoy trabajando. Me he encontrado cosas muy curiosas, como artefactos que dependen transitivamente de versiones anteriores de si mismas (jaxen:jaxen:1.1-beta6 -> jdom:jdom 1.0 -> jaxen:jaxen:1.0FCS), o ver que hay hasta 6 versiones distintas de log4j y 3 de spring-core en el classpath (con los consiguientes errores en los tests que acarrea esta última).

Para evitar esto debemos realizar un estudio a fondo de las dependencias del proyecto y poner los exclude necesarios en el POM. Esta tarea es prácticamente imposible si no se dispone de algún tipo de herramienta que analice por nosotros el POM obteniendo un listado de dependencias (directas y transitivas).

Mi primera opción ha sido una pequeña aplicación Java de escritorio: Maven Dependency Browser. En la propia página de esta herramienta se lee que ya no está siendo evolucionada, debido a que ha sido incluida como parte del proyecto Q4E y se mantiene de forma conjunta.

Q4E es un plugin para Eclipse que integra el uso de Maven con el IDE. Además incluye algunas herramientas como el citado Maven Dependency Browser, pero la funcionalidad que más me ha sorprendido es Maven Dependency Viewer, y como muestra un botón:

Se trata del grafo de dependencias del módulo sonar-web del proyecto Sonar. Evidentemente, así es más fácil trabajar.

Hace unas semanas me encontré con este interesante plugin para Maven: Maven Dashboard Report Plugin.

Con el paso del tiempo se van incluyendo plugins de generación de reportes a nuestros proyectos, pero llega un momento en que la información es tanta y tan dispersa (PMD, Findbugs, Checkstyle, Surefire Report, etc) que empieza a dejar de ser útil. Es aquí donde surge la necesidad de aglutinar la información en un dashboard que nos proporcione de un vistazo la información que requerimos, pudiendo profundizar posteriormente en el aspecto que consideremos oportuno. Precisamente esto es lo que ofrece Maven Dashboard Report Plugin.

Mediante gráficos resumen y datos globales obtenemos una visión general de todos los reportes que se han citado anteriormente.

Otro aspecto muy interesante es la posibilidad de usar una base de datos para almacenar un histórico de los reportes, pudiendo generar gráficos que muestran la evolución a lo largo del tiempo de nuestros reportes.

Estoy configurándolo en un proyecto Open Source que conozco desde hace algún tiempo, en cuanto lo tenga dejaré caer por aquí los resultados.

Hace tiempo estuve desarrollando un stack de servicios web que dieran acceso a una serie de
procedimientos almacenados en una base de datos Oracle. Uno de los objetivos fue automatizar
totalmente el proceso de construcción de los web services con Maven.
La solución se basó en el framework WS de Apache, Axis2 1.3, que en principio ofrece un conjunto
de herramientas en línea de comandos para la generación del código tanto del servicio como de
los clientes. Para la generación del código del servicio se ejecuta:

wsdl2java -uri InterfazWS.wsdl -p interfaz.ws -o target_directory -d xmlbeans -s -ss -sd

Esto genera todos los artefactos necesarios para gestionar las peticiones al web service, solo
tenemos que implementar la lógica de la clase Skeleton.

Este proceso es algo tedioso cuando se esta desarrollando, y además necesitamos tener instalado wsdl2java para generar el código, vamos a automatizarlo con maven, de forma que solo tenemos que ejecutar el comando anterior una sola vez, la primera, para que nos genere la clase Skeleton, esta clase es la que pondremos como fuente de nuestro proyecto (en src/main/java). Desde luego, en el momento del despliegue del servicio no tendremos que ejecutar wsdl2java en la línea de comandos.

La estructura del proyecto será la siguiente:

- -+ src
- - - -+ main
- - - - - - - -+ java
- - - - - - - - - - -+ InterfazWSSkeleton.java
- - - - - - - -+ resources
- - - - - - - - - - - - -+ META-INF
- - - - - - - - - - - - - - - - -+ InterfazWS.wsdl
- -+ interfaz-ws-soapui-project.xml
- -+ pom.xml


Utilizaremos el plugin axis2-wsdl2code-maven-plugin para la generación del servicio
a partir del WSDL (e la fase generate-sources).

Pero este plugin genera todo el código en el directorio que le indiquemos, en nuestro caso target/generated-by-axis2, ahora tenemos que moverlo a src/main/java. ¿Por que no haberlo generado directamente en src/main/java?, por que entonces se sobreescibiría la clase Skeleton y no queremos que pase esto, es en ella donde dotaremos de lógica al servicio y hay que mantenerla, de hecho, será la única clase que tendremos en src/main/java, el resto se generará. Para mover los fuentes y el resto de recursos utilizaremos maven-antrun-plugin.

El segundo objetivo es automatizar las pruebas, lo haremos con maven-soapui-plugin. Este plugin
necesita un fichero xml generado con la herramienta SoapUI. Por tanto debemos definir nuestros
tests con SoapUI y utilizar el fichero xml en el que la herramienta almacena la información de
los tests definidos. A este plugin solo hay que indicarle donde encontrar el fichero xml de SoapUI
y la URL del servidor en el que se encuentra el servicio (el path al wsdl ya lo contiene el xml de SoapUI).
Por último también tenemos que configurar el plugin maven-clean-plugin para que elimine lo que nos
interesa.

Una vez configurado todo, podemos generar y testear el servicio web automaticamente con maven.
El proceso completo consta de los siguientes pasos:

mvn package

- Genera un jar que podemos desplegar en el Axis Manager (WAR) (o en nuestra aplicación web, en
caso de que la hayamos adaptado para desplegar servicios Axis2)

mvn eviware:maven-soapui-plugin:test

- Ejecución de tests funcionales

mvn eviware:maven-soapui-plugin:loadtest

- Ejecucuión de tests de carga

Aún no lo he probado con la versión 1.4 de Axis, en cuanto lo pruebe comento como ha ido.

Este es el fichero pom.xml completo

La calidad del software es un concepto en ocasiones algo abstracto. Qué mejor forma de concretar
un idea que con números. Seguramente todos hemos escuchado la famosa frase de Tom DeMarco: “no
podemos controlar lo que no podemos medir“, pues bien, Sonar nos da una herramienta de medición bastante completa, y por tanto, control.

Llaman la atención especialmente medidas como la mantenibilidad o la eficiencia del código.

Por otro lado su utilización es bastante sencilla, basta con deplegar nuestro proyecto modelado con
Maven ejecutando:

mvn org.codehaus.sonar:sonar-maven-plugin:1.2:sonar

Este aspecto ofrece la posibilidad de integrar Sonar con nuestro sistema de integración contínua, solo hay que definir este “build” además de los que tuviéramos definidos previamente y periódicamente se realizará un analisis estático del código del que obtendremos métricas muy interesantes.

CubicTest es un plugin para Eclipse que permite el diseño de tests funcionales para Selenium y Watir. La verdad es que Selenium IDE ya ofrece una interfaz bastante amigable con la posibilidad de recordar la interacción del usuario sobre la aplicación para reproducirla de forma automática posteriormente, pero la posibilidad de tener una prueba cuya secuencia de ejecución puede observarse de un vistazo es bastante interesante.

Mientras que Selenium IDE nos muestra esto:

Con CubicTest tenemos esto:

Sin duda, la forma en que se se trabaja con algo es importante, y en el mundo del testing más aún, donde el orden y la claridad es fundamental.

Además, CubicTest genera un fichero pom.xml con los tests definidos usando el plugin cubictest-selenium-runner-maven-plugin para utilizar en nuestro proyecto maven.

Aún no he probado Watir, lo pondré en la lista de “pendiente de tener un hueco”.

NetBeans 6.0 ofrece una serie de funcionalidad relacionada con proyectos modelados con Maven realmente sorprendente. De entrada reconoce un proyecto Maven como propio, es decir, no es necesario ejecutar mvn netbeans:netbeans (supongo que el plugin lo hará internamente pero para el usuario es transparente). Además ofrece de una forma cómoda la ejecución de las fases más típicas de maven (package, install, etc). En realidad ofrece lo mismo que Eclipse, pero a mi parecer lo hace de una forma más intuitiva y ágil.

Si ha esto le añadimos la funcionalidad ofrecida por SQE en NetBeans, tenemos un procedimiento potente para analizar el código de un proyecto maven. Por ahora el proyecto SQE esta en fase incubator, pero a priori parece bastante interesante. He probado su funcionamiento integrado en el IDE la verdad es que funciona bastante bien, y los reportes generados (Find Bugs, Checkstyle y PMD) estan muy bien organizados.