http://concordion.googlecode.com/svn/repos/releases

Para los que tengáis un proyecto en GoogleCode y no sepáis cómo publicarlos en el Repositorio Central de Maven, podéis echar un vistazo al wiki del proyecto Concordion donde explico (en inglés) cómo hacer una release usando maven-release-plugin. También os resultará útil ver la solicitud que hice en el JIRA pues allí he ido relatando cómo he ido resolviendo el asunto. Lo siento, todo está en inglés, pero os lo puedo resumir:

1) Usar Maven 2.0.9 (yo utilizaba el embedder y hasta que no pasé a la 2.0.9 no conseguí avanzar)
2) Usar dav:https://concordion.googlecode.com/svn/repos/releases en la sección distributionManagement del pom.xml
3) Incluir username y password en nuestro settings.xml (tenemos que ser desarrolladores del proyecto para poder hacer commit en SVN, así que también para hacer deploy con Maven)

El último paso es, depués de hacer release, crear una entrada en el JIRA solicitando la sincronización. Yo he utilizado estos valores y estoy a la espera de conocer el veredicto.

“org.concordion”,”/home/maven/repository-staging/to-ibiblio/maven-svn”,”svn”,”Jose M Beas”,”jose.m.beas@gmail.com”,,”http://concordion.googlecode.com/svn/repos/releases/”

La parte fácil

Antes que nada, os cuento lo que yo suelo hacer con el código cada vez que termino una iteración.

Supongamos que la versión actual es la 0.0.1-SNAPSHOT.

1) Me recorro todos los pom.xml donde he puesto 0.0.1-SNAPSHOT y le quito el -SNAPSHOT.
2) Hago commit de los pom.xml que he cambiado.
3) Etiqueto esta versión del código en el repositorio (en mi caso Subversion).
4) Vuelvo a recorrer todos los pom.xml para dejar la siguiente versión: 0.0.2-SNAPSHOT.
5) Hago commit de los pom.xml.

Y eso todas las veces…

Pues bien, resulta que hay un plugin de Maven que hace todo eso por mi: maven-release-plugin.

Antes de empezar yo aconsejo también hacer mvn clean install, pero no es obligatorio. Yo es que soy un poco obsesivo con estas cosas.

Para usarlo no puedo tener ningún “commit” pendiente, de lo contrario, el plugin se quejará. Es obligatorio también proporcionar la información de dónde está nuestro repositorio, para ello debemos incluir el apartado “scm” en los pom.xml que lo requieran (según los tengamos organizados):

   https://shopaas.googlecode.com/svn/trunk/shopaas  scm:svn:http://shopaas.googlecode.com/svn/trunk/shopaas  scm:svn:https://shopaas.googlecode.com/svn/trunk/shopaas 

El plugin sustituirá en estas cadenas los valores adecuados, por eso es aconsejable revisar cómo quedan estas secciones de los pom.xml las primeras veces.

Lo primero que hay que hacer es:

mvn release:prepare -DdryRun=true

Esta instrucción cubre los pasos 1, 2 y 3. La propiedad “dryRun” nos sirve para decirle al plugin si queremos o no hacer efectivos los cambios, si le damos el valor “true”, el plugin NO hará commit ni tag. También comprueba si hay dependencias con artefactos cuya versión aún es SNAPSHOT, pero esto no lo he probado, la verdad. Además, “release:prepare” ejecuta por defecto los siguientes “goals” sobre el proyecto: “clean verify”. Esto hace que se ejecuten las pruebas.

Cuando lo ejecutemos, por la consola Maven nos preguntará la versión de cada pom.xml (él no quita el “-SNAPSHOT” sino que pone la versión que nosotros le digamos). También nos pregunta cuál es el nombre con el que va a etiquetar esta versión en el repositorio de control de versiones. Y por último nos pregunta cuál es la versión que vamos a tener para trabajar después de este versionado (que suele ser la siguiente con el “-SNAPSHOT”). El plugin nos propone valores por defecto que podemos aceptar pulsando “intro”. Para cada pom.xml, la ejecución con “dryRun=true” nos dejará 3 ficheros: pom.xml.releaseBackup, pom.xml.tag y pom.xml.next, que se corresponden con el que tenemos antes de ejecutar (0.0.1-SNAPSHOT), el que se etiquetará como versión estable (0.0.1) y el que quedará en el “trunk” con la nueva versión de trabajo (0.0.2-SNAPSHOT). Pero el plugin no hará efectivos estos cambios porque le hemos dicho “dryRun=true”.

La parte difícil

Hasta aquí todo iba bien, pero el siguiente paso me dio problemas. Pero primero hay que ejecutar sin “dryRun” para que se hagan efectivos los cambios en SVN.

mvn release:clean release:prepare

release:clean sirve para limpiar los ficheros que haya podido dejar una ejecución anterior. También podemos usar releas:rollback para deshacer los cambios efectuados en SVN.

El primer obstáculo fue al usar el Maven embebido que viene con m2eclipse. Así que tuve que pasar a usar una instalación externa (concretamente la 2.0.9).

El segundo obstáculo fue al ejecutar el comando y encontrarme con el siguiente mensaje de error:

[INFO] Executing: cmd.exe /X /C "svn --non-interactive commit --file C:\Temp\maven-scm-2032301768.commit --targets C:\Temp\maven-scm-5209016095571570993-targets"[INFO] Working directory: C:\eclipseWorkspaces\MiTienda\shopaas[INFO] Tagging release with the label shopaas-0.0.1...[INFO] Executing: cmd.exe /X /C "svn --non-interactive copy --file C:\Temp\maven-scm-328141097.commit . https://shopaas.googlecode.com/svn/tags/shopaas-0.0.1"[INFO] Working directory: C:\eclipseWorkspaces\MiTienda\shopaas[INFO] ------------------------------------------------------------------------[ERROR] BUILD FAILURE[INFO] ------------------------------------------------------------------------[INFO] Unable to tag SCMProvider message:The svn tag command failed.Command output:svn: Commit failed (details follow):svn: File '/svn/tags/shopaas-0.0.1/domain/pom.xml' already exists

El caso es que hay un bug (¡cómo no!) que, para colmo, no parece estar claro si está del lado de Maven o de SVN. Parece que maven-release-plugin hace “svn copy” para crear el tag y que, a partir de la versión 1.5.1 de Subversion esto mismo ha comenzado a fallar. Así que hay que hacer manualmente la siguiente chapu:

# mvn release:prepare=> fails# svn up -r head # mvn release:prepare -Dresume

De esta manera, los ficheros en .svn que han quedado chungos se arreglan con “svn up” y luego se continúa por donde se había quedado (con -Dresume). Con Eclipse consiste en primero hacer “Team / Update” y a continuación ejecutar Maven con el goal “release:prepare” y el Parameter “resume” (al que tenemos que ponerle el valor “true” porque la configuración del launcher que propone m2eclipse no permite añadir un parámetro con nombre pero sin valor).

Llegados a este punto podemos revisar que en nuestro servidor de SVN se han creado tres nuevas revisiones con el siguiente comentario:
* [maven-release-plugin] prepare release shopaas-0.0.1
* [maven-release-plugin] copy for tag shopaas-0.0.1
* [maven-release-plugin] prepare for next development iteration

Los ficheros que son cambiados tras la ejecución (los pom.xml) podemos compararlos con las correspondientes versiones anteriores. En mi ejemplo, el mismo trozo del pom.xml que muestro más arriba queda como:

   https://shopaas.googlecode.com/svn/tags/shopaas-0.0.1  scm:svn:http://shopaas.googlecode.com/svn/tags/shopaas-0.0.1  scm:svn:https://shopaas.googlecode.com/svn/tags/shopaas-0.0.1 

Y en nuestro espacio de trabajo tenemos que la versión de los diferentes pom.xml ha quedado ahora como 0.0.2-SNAPSHOT, tal y como respondimos en su momento. También nos ha quedado un fichero release.properties con todas las versiones y trayectorias en SVN de los componentes versionados por este plugin.

Queda pendiente

Me queda aún por probar a realizar el despliegue de la nueva versión de manera automatizada. Para ello hay que usar el goal “release:perform”, que según parece ejecuta por defecto los goals “deploy site-deploy” después de obtener dicha versión desde el servidor de control de versiones.

Concordion

Las principales características de Concordion son:

• Las especificaciones se escriben en XHTML

• libertad absoluta de formato, que favorece escribir las especificaciones orientadas a comprobar los comportamientos en vez de orientadas a “scripts”
• no es necesario conocimiento técnico para poder escribir las especificaciones

groupId

org.concordion

artifactId

concordion

version

1.3.0

• el resultado de la ejecución son los mismos XHTML pero iluminando los textos instrumentados con verde si se cumple la condición, rojo si no se cumple o amarillo si se ha producido una excepción
• también hay un plugin Maven que produce un resumen del resultado de la ejecución que recorre todos los XHTML resultantes y que mejora el que produce el plugin Surefire para los JUnit

Proyecto de ejemplo

He creado un proyecto en GoogleCode para, entre otras cosas, ir realizando todas estas pruebas. Anteriormente había escrito un artículo donde se trataba de ilustrar el uso de Spring y de JPA juntos. Ahora he incorporado un ejemplo que ilustra cómo pasar de una historia de usuario sobre el Mantenimiento de un Catálogo de Productos para una tienda. Esto es un poco CRUD, pero poco a poco iremos viendo cómo incluso en ese escenario podemos orientarnos al comportamiento.

¿Cómo descargar y probar este ejemplo?

Para descargar este proyecto podéis seguir las instrucciones:

svn co http://shopaas.googlecode.com/svn/trunk/shopaas shopaas

Podéis revisar los siguientes detalles por si queréis cambiarlos.
En shopaas/pom.xml

…y a continuación podéis construirlo usando Maven. Para ello, ejecutad:

cd shopaasmvn clean install cobertura:cobertura site

Si todo ha ido bien, podréis comprobar que se ha generado un “site” del proyecto en la carpeta target/site.

Desgraciadamente no he conseguido aún que queden correctamente enlazados los módulos, por lo que es necesario ir hasta la carpeta shopaas/services-acceptance-test/target/site y abrir el fichero index.html con nuestro navegador favorito para poder ver el resultado de las pruebas de aceptación (incluso el informe de cobertura de las mismas).

Si ejecutáis la construcción del proyecto desde la linea de comandos, es posible también que tengáis un problema de falta de memoria (Error “Java Heap Space”), para evitarlo tendréis que ejecutar antes que nada “set MAVEN_OPTS=-Xmx128m”. A mi me ha dado este problema cuando lo he probado en Windows XP con un JDK 1.6.0_11, y sospecho que tiene que ver con los valores por defecto que elige la JVM en este entorno. Pero tampoco lo tengo 100% seguro.

maven-concordion-plugin

No sé si para el momento en el que probéis esto ya estará publicado en el Repositorio Central de Maven el plugin que permite obtener informes resumidos de Concordion. Si no fuera así, también deberéis descargar el código del maven-concordion-plugin y construirlo con mvn install.

Cobertura

El informe de cobertura del código (“code coverage”) ha sido algo que me ha costado especialmente puesto que el código a instrumentar no está en el mismo módulo que las pruebas, de modo que he usado una combinación de los plugins maven-antrun-plugin y build-helper-maven-plugin. Como podréis comprobar, así podemos conocer con bastante certeza si hay código que llevamos a producción para el que no tenemos ninguna prueba. Mmmm, sí que es interesante, ¿verdad?

Automatización

Pero lo más interesante es que está completamente automatizado. También están las pruebas de aceptación de la UI que os mostré en un artículo anterior. Por tanto, tenemos pruebas unitarias de los componentes internos, pruebas de aceptación de los servicios de aplicación (escritas en lenguaje de negocio) y pruebas de aceptación de la UI (independientes de la implementación de los servicios de aplicación, o no, esa es nuestra decisión). Con lo que sólo nos queda, en cada “release”, darnos un paseo por la aplicación por aquellos puntos críticos o para los que el coste de hacer una prueba automática sea excesivo. Pero el resultado neto es que hemos ganado en confianza y reducido el tiempo que tardamos en entregar un proyecto. En estos tiempos de crisis, eso es importante, ¿verdad?

Recursos

También hay disponible un tutorial de Concordion. Además, a continuación incluyo una lista de enlaces de interés:

• Ejemplo
• Técnica

Feedback (o reacciones)

Por favor, espero que me hagáis llegar vuestros comentarios cuando probéis esto. Me ayudarán mucho a mejorar este ejemplo. No tengo claro cómo organizar el código para que Maven me construya todo como es debido y eso le resta claridad al resultado final, que debería ser que el “Product Owner” o los “expertos del dominio” pudieran navegar hasta el resultado de las pruebas de aceptación y discutir tanto sobre su definición como sobre el resultado de la ejecución.

También hay dos conjuntos de código diferentes: users y products. El primero corresponde a aquel ejemplo que hice hace ya unos meses y el segundo es el que he estado trabajando últimamente y que pretendo que me sirva como piedra de toque para ir encontrando patrones o plantillas.

• Maven. Con Maven gestionamos el ciclo de vida de la construcción y las pruebas, así como las dependencias entre artefactos.
• Cargo. Con este plugin Maven realizamos el despliegue de la aplicación web en el contenedor de nuestra elección.
• Selenium Webdriver. Con este framework y el correspondiente plugin Maven ejecutamos las pruebas funcionales.
• Jetty. Éste es el contenedor web de mi elección. (Podría haber sido Tomcat, Glassfish o cualquier otro).
• JUnit. Como framework de pruebas.
• Wicket. Éste es el framework web de mi elección.

Todo el código fuente lo tenéis disponible en GoogleCode.

Pruebas unitarias

En Eclipse y con m2eclipse he creado el proyecto raíz con dos módulos: web (de tipo war) y web-integration-test (de tipo pom). El proyecto web lo he creado con el arquetipo “org.apache.wicket:wicket-archetype-quickstart:1.4-rc1″ y luego lo he tocado un poco.

< ?xml version="1.0" encoding="UTF-8"?>
 
  shopaas  shopaas  0.0.1-SNAPSHOT  4.0.0 shopaas web 
war Web Application 0.0.1-SNAPSHOT UI wicket para Shop As A Service   shopaas-web         src/main/resources          src/main/java         **             **/*.java                  src/test/java         **             **/*.java          
 
    maven-compiler-plugin    true         1.5     1.5     true     true        
    org.mortbay.jetty    maven-jetty-plugin         10            
8080       60000                   
    maven-eclipse-plugin         true                org.apache.wicket   wicket   ${wicket.version}       org.slf4j   slf4j-log4j12   1.4.2       log4j   log4j   1.2.14       junit   junit   4.5   test       org.mortbay.jetty   jetty   ${jetty.version}   provided       org.mortbay.jetty   jetty-util   ${jetty.version}   provided       org.mortbay.jetty   jetty-management   ${jetty.version}   provided    
  6.1.14  1.4-rc1 

No quiero entrar en detalles sobre cómo es una aplicación Wicket, pero sí explicaré los dos detalles más importantes:

Si quiero desplegar la aplicación en Jetty no tengo más que ejecutar Maven con el “goal” jetty:run, pero esto sólo nos sirve para probar manualmente nuestra aplicación. (Por cierto, el puerto 8080 es el puerto por defecto, pero me gusta explicitar esta configuración).

Wicket proporciona la clase WicketTester, que permite probar la aplicación fuera del contenedor, mediante una simulación del mismo. De esta manera podemos hacer pruebas unitarias de todos los componentes de nuestra GUI sin necesidad de empaquetarla y desplegarla. Más adelante, en futuros artículos, tengo previsto entrar en detalle en cómo desarrollar la GUI con Wicket haciendo TDD.

package shopaas;

import junit.framework.TestCase;import org.apache.wicket.util.tester.WicketTester;

/** * Simple test using the WicketTester */public class TestHomePage extends TestCase{ private WicketTester tester;

 @Override public void setUp() {  tester = new WicketTester(new WicketApplication()); }

 public void testRenderMyPage() {  //start and render the test page  tester.startPage(HomePage.class);

  //assert rendered page class  tester.assertRenderedPage(HomePage.class);

  //assert rendered label component  tester.assertLabel("message", "If you see this message wicket is properly configured and running"); }}

Esta prueba es muy simple, pero lo suficiente como para ver “por dónde van los tiros”. Como podéis comprobar, llegados a este punto podemos tener las pruebas unitarias de nuestra aplicación web completamente automatizadas y, por tanto, incluidas en nuestro sistema de integración continua sin mayor problema.

Pruebas funcionales

Pruebas funcionales o de integración son términos muy usados pero no tengo claro que todo el mundo entienda lo mismo cuando los usa. Lo que yo estoy llamando aquí pruebas funcionales o de integración son aquellas en las que pruebo el sistema desplegado (hasta donde se puede razonablemente). Pues bien, lo que voy a enseñar ahora es cómo desplegar de manera automática el war de nuestra aplicación y lanzar (automáticamente también) las pruebas.

Para esto he usado Cargo y he modificado el ciclo de vida de varios plugins (compiler, surefire y el propio cargo) para que se ejecuten en el orden adecuado. Además, he usado Selenium Webdriver para escribir y ejecutar las pruebas.

Al ejecutar (desde el proyecto raiz) Maven con el goal “integration-test”, el propio Maven estudia las dependencias entre artefactos y empaqueta el war (y ejecuta sus pruebas) antes de pasar a desplegar ese war en un Jetty 6 que se arranca y detiene solamente para ejecutar las pruebas de integración.

 4.0.0 
  shopaas  shopaas  0.0.1-SNAPSHOT  web-integration-test 
pom Functional Tests      shopaas   web   0.0.1-SNAPSHOT   war       junit   junit   4.5   test         org.openqa.selenium.webdriver   webdriver-htmlunit   0.6.685       org.openqa.selenium.webdriver   webdriver-support   0.6.685         org.mortbay.jetty   jetty   ${jetty.version}   provided       org.mortbay.jetty   jetty-util   ${jetty.version}   provided       org.mortbay.jetty   jetty-management   ${jetty.version}   provided       
 
    org.apache.maven.plugins    maven-compiler-plugin         1.5     1.5     true     true                          testCompile                   
    org.apache.maven.plugins    maven-surefire-plugin          
integration-test             test                   
    org.codehaus.cargo    cargo-maven2-plugin         false                          shopaas        web        war 
         /                          

               start 
pre-integration-test             start                      stop 
post-integration-test             stop                      
 
   jetty6x       true    
    6.1.14       
 
      org.codehaus.cargo      cargo-maven2-plugin                     jetty6x        embedded               
         8080         medium               
          

El único test que he incluido como prueba de concepto contiene dos tipos de prueba (una con Webdriver y otra sin él, la anotada con @Ignore).

package shopaas.web.integration.test;

import static org.junit.Assert.assertEquals;

import java.net.HttpURLConnection;import java.net.URL;

import org.junit.Before;import org.junit.Ignore;import org.junit.Test;import org.openqa.selenium.WebDriver;import org.openqa.selenium.htmlunit.HtmlUnitDriver;

public class WebappTest {

 @Ignore @Test public void testCallIndexPage() throws Exception {  URL url = new URL("http://localhost:8080/");  HttpURLConnection connection = (HttpURLConnection) url.openConnection();  connection.connect();  assertEquals(200, connection.getResponseCode()); }

 private WebDriver driver;

 @Before public void setUp() {  driver = new HtmlUnitDriver(); }

 @Test public void testHomepage() {  driver.get("http://localhost:8080/");  assertEquals("Wicket Quickstart Archetype Homepage", driver.getTitle()); }

}

He utilizado el HtmlUnitDriver que, aunque también es una emulación de una navegador, para mi es suficiente, no me complica mi entorno y además es más rápido. Pero si quisiera utilizar Firefox, Safari o Internet Explorer, no tendría más que cambiar el driver correspondiente. Lógicamente, podemos tener la misma prueba con un driver diferente y estaremos asegurando que nuestra aplicación funciona para varios navegadores. Mmmmm, veo que he captado vuestra atención…

Problemas encontrados

Al poner todo esto en pie he estado bastante tiempo atascado porque cada vez que ejecutaba las pruebas de integración obtenía un mensaje de error en Jetty diciendo que no era capaz de arrancar la aplicación porque “No suitable Log constructor”. No entiendo de dónde sale el dichoso commons-logging, pero el caso es que poniendo el fichero commons-logging.properties en el classpath de la aplicación web (para que se empaquete en el war), todo pasó a funcionar perfectamente.

org.apache.commons.logging.Log=org.apache.commons.logging.impl.SimpleLog

El otro inconveniente que tuve es más un detalle al que prestar atención que otra cosa. Se trata del valor del contexto que hay que poner en la configuración de Cargo, que debe coincidir con el valor usado en el URL de la aplicación en nuestras pruebas y en el fichero web.xml de la aplicación web.

 
    org.codehaus.cargo    cargo-maven2-plugin         false                          shopaas        web        war 
         /                          

                                    ...       

Bien, creo que esto es todo. Si tenéis interés y el código de ejemplo no es suficiente, no dudéis en preguntarme y trataré de ayudaros.

• Preparando Eclipse para Maven con m2eclipse
• Configurar Eclipse para trabajar con Maven

Para los que queráis ahondar en el tema (en inglés) os recomiendo el wiki del proyecto m2eclipse.

Por cierto, el artículo lo estoy traduciendo a ratitos y surgió como consecuencia de una pregunta que hice en la lista “ecosistemas-software” (que aprovecho para recomendar) en la que encuestaba sobre las alternativas para usar Maven en Eclipse: m2eclipse y Q4E.

Cuando tenga terminada toda la traducción os lo haré saber.

Editado:
He cambiado la dirección donde he publicado la traducción. Espero que si hay errores en la traducción me lo hagáis saber para corregirlos, gracias.

Después de buscar y buscar cómo instalar el módulo de code coverage de TPTP me he encontrado con que han abandonado el desarrollo para usar justamente EclEmma. Bueno, eso me ha simplificado el trabajo.

Así pues, después de instalar EclEmma, probar la cobertura de mis tests JUnit ha sido muy fácil. Simplemente he seguido las instrucciones. (Ejem, he de reconocer que las seguí después de ver que me estaba calculando la cobertura ¡¡de los propios tests!!)

Para que no incluya nuestros tests en el informe de cobertura hay que:

• pulsar en el menú “Run / Coverage”,
• seleccionar la configuración de nuestro test,
• pulsar en la pestaña “Coverage”
• y desmarcar la carpeta correspondiente (en mi caso src/test/java porque uso Maven)

Como suponía, mi cobertura era del 100%.

De todos modos, no tener un plugin estable de Emma para Maven2 hace difícil el incorporarlo al proceso de integración continua (puesto que yo he optado por tenerlo todo con Maven2 y no usar Ant ni otros procesos añadidos). En cualquier caso, en cuanto pueda lo probaré a ver qué tal…

P.S.
Si alguien tiene interés, incluyo el enlace a una presentación sobre EclEmma de la EclipseCon 2008 que puede aclarar cómo funciona por dentro (incluidas referencias a OSGi).