Q4E Dependency Viewer: Maven y las dependencias transitivas

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.

Maven Dashboard Report Plugin: recopilando la información

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.

Construcción y Testing de Web Services con Axis y Maven

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

Sonar: Medidas de la calidad del software

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.

Diseñar pruebas de forma gráfica

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”.