Xnoccio

Después de una serie de artículos que se iniciaron con Eligiendo nuestro entorno de Integración Continua (I) , tenemos las conclusiones finales de nuestra comparativa.

• Tabla resumen

A modo de resumen hemos agrupado en una sola tabla todos las parámetros evaluados en la comparativa, para permitirnos una comparación rápida entre las diferentes herramientas.

• Conclusiones finales.

Sin duda nuestra propuesta se inclina por Hudson. Brevemente vamos a enumerar y resumir (de entre los detalles de esta comparativa) ciertos aspectos que hacen inclinar la balanza hacia este software:

• Extensibilidad. La posibilidad de desarrollar plugins que permitan adaptar e inyectar funcionalidad de forma personalizada es una característica casi imprescindible.  Apache Continuum no dispone de esta posibilidad de integrar plugins (deben ser plugins Maven, utilizados específicamente en cada uno de los proyectos Java), lo cual prácticamente hace descartar esta plataforma. LuntBuild dispone de ciertas opciones de inyección de código, si bien a este respecto las mejores características las tiene Hudson.

• Calidad de la documentación. En esta materia Hudson también dispone de la mejor documentación, por delante de LuntBuild y Continuum.

• Integración de resultados de plugins (centralizados o Maven) en pantalla. Un aspecto de interés es que el resultado de los diversos plugins pueda verse en la interfaz web de la aplicación. Tan sólo Hudson proporciona este nivel de integración por defecto.

• Sistema de seguridad y permisos. En esta funcionalidad tan importante lideran la comparativa Hudson y Continuum. Ambas disponen de la posibilidad de gestión de permisos basados en perfiles, y posibilidad de personalizar los permisos por proyectos. Continuum puede requerir modificaciones en ficheros de configuración y reinicio del sistema, mientras que Hudson permite configuración integral en pantalla.

• Estabilidad. Las tres plataformas disponen de buenas características de estabilidad, si bien destacan Hudson y LuntBuild, que permiten la gestión multihilo y compilación distribuida.

• Soporte de la comunidad. A este respecto lideran la comparativa tanto Hudson como Continuum, desarrollos de Sun y Apache respectivamente.

Como se puede observar, Hudson auna las principales características que nosotros esperabamos de un sistema de Integración Continua, y por ello es nuestra propuesta y elección para servir de plataforma base en la infraestructura de desarrollo.

Formul@ (léase Formula) es un software desarrollado por VIAVANSI (cuyo desarrollo finalizó en 2007), que permite diseñar visualmente (mediante una interfaz Ajax con funcionalidades de drag&drop) formularios dinámicos que posteriormente pueden ser utilizados remotamente por otras aplicaciones. Ello es debido a que la necesidad de gestión visual de “dynamic forms” es cada vez más común y recurrente en multitud de proyectos. ¿En cuántos sistemas de información existe el requisito de disponer de formularios de entrada de datos, y cuánto esfuerzo de desarrollo y mantenimiento evolutivo implica?

Nuestra idea consistió en desarrollar un componente específico especializado que se responsabilizase de esta tarea dentro de una arquitectura de servicios, del mismo modo que se usa un servidor de base de datos para persistir información o se usa un servidor SMTP para enviar un email.

Básicamente y a grandes rasgos, Formul@ se encarga de las siguientes tareas:

• Definición visual de formularios complejos.
• Almacenamiento de la definición en un metamodelo XML.
• Rendeo de los formularios bajo demanda de aplicaciones cliente. Nótese que al basarse en una definición modelada en XML, del mismo modo que un formulario se rendea en web, podría rendearse en una aplicación de escritorio, en un teléfono móvil, etc… Un sólo trabajo de definición, múltiples salidas para el formulario.

Te invitamos a que pruebes la demo del diseñador de formularios Formul@.

A nivel técnico Formul@, que inicialmente surgió como desarrollo interno de I+D, hace uso de las últimas tecnologías disponibles en el mundo Java como son Java Server Faces (JSF), Java Persistent Api (JPA, Ajax, Maven, Web services usando JSR 181, XSL-FO, etc.

A nivel funcional, si probáis la demo del diseñador podréis observar que pueden crear varias páginas, dentro de las páginas bloques de varios tipos, dentro de éstos contenedores para maquetar, dentro de los contenedores campos de diversos tipos… Y luego las aplicaciones cliente pueden usar y controlar el comportamiento de los formularios a través de un API.

Formul@ ha sido desarrollada para la Junta de Andalucía, por lo que está liberada como software libre dentro del Repositorio de Software Libre de la Junta de Andalucía.

Actualmente estamos trabajando para la Junta con el objetivo de incluir muchas mejoras en el motor. ¡Pon Formul@ en tu vida!

PD: Formul@ no sólo se ha utilizado en varios proyectos de desarrollo de VIAVANSI, como no podría ser de otra forma… por ejemplo, otras empresas (como nuestros colegas de Guadaltel, ahí va una referencia gratuita en agradecimiento por el paintball) lo han utilizado (dentro del ámbito local andaluz) como motor visual de formularios dinámicos en la Oficina Virtual del Ayuntamiento de Córdoba, en el sistema de Comunicaciones Internas eCO de la Junta de Andalucía, en el ambicioso Sistema de Gestión Global del Gasto (G3) de la Junta de Andalucía, etc.

Hola buenas a tod@s,

esta vez os escribo para comentaros un quebradero de cabeza más que me ha dado Windows Vista e iTunes (con Quicktime), un par de problemas:

1) Cada vez que arranco el iTunes, se vuelve a reinstalar.

2) Se produce un error de ActiveX al abrir el Quick Time Player: Error 46

Para el primero de los problemas, la solución fue un poco drástica: eliminar el acceso directo del iTunes que tenemos en el Escritorio y crear un nuevo acceso directo al iTunes.exe que tenemos en nuestra carpeta de “%Program Files%/iTunes”, lo colocamos en nuestro Escritorio y aquí no ha pasado nada :-D

Para solucionar el segundo error ya tenemos que hacer un par de cosillas más.

Primero os comento cuál es la causa de este error:
Parece ser que al instalar QuickTime Player las claves introducidas en el registro  de Windows Vista no adquieren permisos de acceso correctos. Exactamente lo que ocurre es que nuestro usuario (sea Administrador o no) no tiene acceso ni siquiera de lectura a dichas claves.

Esto os lo cuento yo y queda muy bonito ¿verdad?, pero ¿cómo podeis comprobar esto vosotros mismos?
Pues descárguense el programa Process Monitor  de Microsoft. Tras instalarlo y dejar abierta la aplicación, intenten abrir QTPlayer y miren los errores que se muestran en el Proces Monitor producen al intentar abrir el QuickTime Player, seguro les aparecerá “ACCESS DENIED” a distintas claves del registro (podeis filtrar las lineas que se muestran).

Pues bien, parece que tenemos claro ahora cuál es el problema, ¿cómo “repcuperar” los permisos de lectura sobre dichas claves?

Si hacemos lo típico, ejecutar “regedit” e intentar modificar los permisos manualmente veremos que no tenemos autorización para realizar estos cambios en esas claves afectadas. ¡Vaya chasco!

Bien, busquemos otra forma de modificar estos permisos. Usemos ahora otro programa de Microsoft llamado SubInACL: esta es una herramienta de administración, para modificar y consultar distintos parámetros del sistema como claves del registro, servicios, etc., pero vamos al grano.

Con este programa tenemos ahora que modificar los permisos asignados a estas claves que no pudimos modificar con “regedit.exe” .

Una vez descargado e instalado, debemos copiar el script que contiene Script.zip y descomprimir el .cmd en la carpeta”%Program Files%\Windows Resource Kits\Tools“, que es donde se debe haber instalado SubInACL.
Este script es parecido a otros que aparecen en algunos foros, pero este en concreto contiene algunas correcciones realizadas por mi y adaptado a Windows Vista en Español, no en Inglés. Recomiendo hacer una copia de seguridad del registro antes de ejecutar nada, siempre es conveniente trabajar sobre seguro.

A continuación, abramos una terminal de consola (Inicio / Ejecutar / cmd.exe para los no iniciados) y vayamos a la carpeta donde copiamos el script. Ejecutemos en la consola “resetSpanish.cmd” y veamos en el log mostrado que no salgan errores:

Done:        X, Modified        X, Failed        0, Syntax errors        0

lo importante es que “Failed”  y “Syntax errors” salgan a cero.

Este script hay que lanzarlo con un usuario Administrador y recomiendo desactivar el sistema de protección de cuentas de que dispone Windows Vista (Panel de Control / Cuentas de Usuario / Activar o desactivar el control de cuentas de usuario),
una vez lanzado el script podeis volverlo a activar.

Una vez hecho esto, podremos abrir “QuickTime Player” sin obtener el dichoso error 46.

Y recordad: siempre tenemos una alternativa en LINUX …

Namasté.

Los señores de Alcakon han tenido a bien introducirnos en la lista de “Professional OpenCms solution providers in Europe“… Con nosotros ya somos 9 las empresas españolas que desarrollan sobre OpenCms recogidas en el listado: Adequa (Barcelona), Consoltic (Málaga), Drago Solutions (Madrid), Encamina (Valencia), GPM Factoría Internet (Salamanca), inxtenso (Barcelona), Open Sistemas (Madrid), openTrends (Barcelona) y Viavansi (Sevilla). Eso sí, como está por orden alfabético, salimos los últimos del listado de proveedores :-D

Enhorabuena a mis compañeros del departamento de Desarrollo de OpenCms.

Resulta curioso cómo la tecnología va y vuelve por los mismos caminos. Partimos de máquinas con poquísima capacidad de cálculo y aplicaciones cliente- servidor, que cedían la mayor parte del esfuerzo de cálculo a una máquina central. Despúes evolucionamos hacia clientes ricos, aplicaciones web, RIA… y en paralelo el mercado se vuelve a plantear utilizar thin clients para los usuarios (como las Sun Ray), aplicaciones en modo ASP nuevamente centralizadas en un servidor…

En el desarrollo web estamos viviendo algo similar. Al principio los esfuerzos por la falta de estándares y la batalla entre IE y Netscape nos traía locos, obligándonos a distinguir qué navegador estaba rendeando la página mediante Javascript. La ausencia de CSS y la maquetación con tablas  hacía que apenas unos pocas combinaciones de sistemas operativos / resoluciones / navegadores daban resultados aceptables. La aparición de los estándares (con la siempre inquietante sombra de IE acechando) nos ayudó a evolucionar. Por otro lado, se podia aceptar como un estándar de mercado que las resoluciones de 640×480 ó 800×600 iban desapareciendo…

Pues véase en la figura una foto de salón que cada vez va a ser más frecuente: la misma página web visualizada en un televisor Full HD de altísima resolución, en un UMPC (en este caso, un Airis Kira) con un monitor de 7 pulgadas y una resolución de apenas 800×480, y en un Ipod Touch con una resolución de 480×320… ¿Alguien puede jurar que la resolución “óptima” es una concreta? En definitiva, deberíamos ir haciendo un rápido rollback de nuestras ideas previas sobre navegadores, resoluciones, sistemas operativos, etc. ¿Acaso alguien duda de que la web 3.0, si algún día la imagina alguien del todo, no será navegada por cualquier tipo de dispositivo móvil?

Es cierto que la adopción de estándares y CSS nos va a ayudar bastante en este tipo de tareas; a priori, una web con HTML bien marcado y unas buenas dosis de CSS puede ser navegada por un gran espectro de dispositivos. Sin embargo, la tecnología es un camino de ida y vuelta, y a nadie le debería de extrañar que en poco tiempo volvamos a tratar de detectar el sistema operativo / navegador cliente*, y personalizarle la interfaz…

Namasté y buena suerte.

*  Y como muestra, un botón: minid ha publicado un framework de desarrollo de aplicaciones para iPhone, basado en xhtml y CSS3 que puede rendear el navegador Safari del iPhone. Gracias a esto, podemos desarrollar aplicaciones web con una apariencia fiel de aplicativo de escritorio iPhone. Así que una misma aplicación web, distinguiendo el cliente, podría ser rendeada específicamente para iPhone. Si teneis uno, o un iPod Touch, probadlo que está bastante interesante.

En el caso de que necesitemos establecer algún tipo de preprocesamiento/filtro/mecanismo de seguridad a un servicio web, una de las formas más interesantes es utilizando los manejadores HandlerChain que proporciona JAX-WS 2.x.

En primer lugar implementamos el manejador, que nos permitirá realizar procesamientos y postprocesamientos sobre las peticiones SOAP que lleguen a nuestro servicios web. Os dejo un ejemplo de un manejador que permite filtrar por ip:

public class SecurityServiceWebHandler  implements MessageHandler{

 private static Log log=LogFactory.getLog(SecurityServiceWebHandler.class);

 public Set getHeaders() {

 	return null;

 }

 public void close(MessageContext context) {

 }

 public boolean handleFault(MessageHandlerContext context) {

 	return true;

 }	/** Comprueba que las ips que acceden a la aplicación son efectivamente ip permitidas.

  * @see javax.xml.ws.handler.Handler#handleMessage(javax.xml.ws.handler.MessageContext)

  */

 public boolean handleMessage(MessageHandlerContext context) {

 	ServletRequest servletRequest = ((ServletRequest)context.get(MessageContext.SERVLET_REQUEST));

                // Obtenemos la ip remota que invoca al Servicio Web

 	String remoteAddres=servletRequest.getRemoteAddr();

 	String allowed=”192.168.10.160,80.58.0.12″;

 	if(StringUtils.contains(allowed, remoteAddres)){

 		if(log.isInfoEnabled())log.info(”Servicio Web solicitado desde ip: “+remoteAddres);

 	}else{

 		log.error(”Acceso denegado. La ip “+remoteAddres+” no tiene permiso para acceder a los WS.”);

 		throw new WebServiceException(”Acceso denegado. La ip “+remoteAddres+” no tiene permiso para acceder a los WS.”);

 	}

 	return true;

 }

}

Una vez implementado el manejador, lo siguiente es publicarlo en el fichero handlerchain.xml

<handler-chains xmlns=”http://java.sun.com/xml/ns/javaee”>
<handler-chain>
<handler>
<handler-class>org.viafirma.conector.security.SecurityServiceWebHandler</handler-class>
</handler>
</handler-chain>
</handler-chains>
El último paso es asociar nuestro servicio web con el manejador, mediante la anotación @HandlerChain.

@HandlerChain(file="handlerchain.xml")

@WebService(serviceName="ConectorFirmaRMIService",targetNamespace = "http://viafirma.org/client/", name = "ConectorFirmaRMIClient",portName="ConectorFirmaRMI",

endpointInterface = "org.viafirma.cliente.firma.rmi.FirmaClienteRMI")

public class ConectorFirmaRMI  extends UnicastRemoteObject implements FirmaClienteRMI {

Como ejemplo, gracias a este código podremos recuperar y registrar las ips de todas las peticiones entrantes a nuestro servicio web, y denegar las ips no admitidas.

Leo con algo de sorpresa la siguiente noticia, que viene a decir que Telefónica ha tenido una ¿novedosa? idea, montando una empresa que sirva de tercero de confianza en transacciones electrónicas. Concretamente, citando al diario El País, Telefónica sabe del hueco de negocio en las transacciones electrónicas basadas en tecnologías de firma digital, por lo que “ha decidido crear una división denominada Mediador de Confianza, que permitirá validar los certificados electrónicos, autentificar las transacciones electrónicas, tanto por Internet como por móvil, y llevar un servicio de custodia de los documentos electrónicos”.

Esto desde luego no es ninguna sorpresa. Siguiendo un modelo tal vez inspirado en Tractis, Telefónica aprovecha su innegable renombre para erigirse en tercero de confianza en transmisiones electrónicas seguras. Supongo que habrán optado por un modelo de negocio de abstraer la lógica a las empresas (hay que tener en cuenta el fuerte posicionamiento de Telefónica en el mercado de PYMEs), proveyéndoles de soluciones sencillas que solucionen problemas complejos como estos.

Sin embargo, lo que me sorprende sobremanera es lo siguiente; vuelvo a citar al diario “El País”: “La operadora lleva trabajando más de un año en el proyecto, con una inversión de más de 400 millones de euros…”.

¿400 millones de euros? Repaso un poco proyectos por orden de coste decreciente, la importante cantidad que costó CERES, lo que le ha costado a la Junta de Andalucía la creación de @Firma, lo que nos ha costado hacer Viafirma (tener a un crack como Félix ayuda, claro)… pero, ¿400 millones de euros?

Divagando un poco, supongo que habrán comprado 100 o 200 servidores Windows, 300 Linux y 400 Sun (hay probar Solaris, Aix o HP UX, para ver si van bien), y estarán comparando. Supongo que hay dos o tres nuevos turistas espaciales. También supongo que estarán programando en ensamblador, que siempre es más seguro, y a ser posible de espaldas y a la luz de las velas en noches de luna llena. Los algoritmos de encriptación existentes no les valdrán, estarán creando los suyos propios basándose en la lectura de las vías tomistas. No estarán programando con las manos, que cada cual se imagine otra parte del cuerpo con la que se pueda realizar pulsaciones de teclado (bueno, tal vez estén programando a boli e intentando escanearlo con un OCR).

Corcho, pero todavía me sobran euros para darme la vuelta al mundo :-)

En todo caso, divagando, he llegado a la conclusión. Telefónica, para el siguiente presupuesto, nosotros te lo hacemos por la mitad de lo que te digan ;-)

Los usuarios somos así: nos sorprendemos rápido, nos enamoramos, pero no puedes fallarnos: tenemos tendencia a ser infieles.

Querido navegador del zorrito: nos conocimos hace muchos años. Ni siquiera eras un zorrito. Te conocí como Phoenix, y te tomé como referencia como Firebird. Empecé contigo con versiones 0.x, y me entusiasmé cuando lanzaste tu 1.0 desde la Preview Release. Tenías unas pestañas que nadie más tenía, y podía añadirte plugins que me hacían la vida más fácil. Las Developer Tools cambiaron mi vida de desarrollador, bloqueabas los pop-ups, recordabas mis contraseñas cuando querías… ¡respetabas los estándares, no como ese capullo de IE! Eras software libre. Molabas mucho. Te recomendé a todo el mundo, sentía que jugaba con los buenos en la lucha contra el poder.

Fuiste evolucionando, llegaste a la versión 1.6, ahí me desencanté un poco, pero no era culpa tuya. Las relaciones largas a veces causan hastío. Yo no te cambiaba por nada… Salió tu versión 2.0. Ahí empezó el desastre. Te cuelgas, te apagas, te cierras solo. Vas lento, más que el resto. Coges mucha memoria. Me obligas a adaptarte, a usar about:config. Los amigos del Mac se fueron un día de safari y nunca volvieron. Una y otra vez me ofrecías restaurar la sesión. A los usuarios nos gusta llevar el control, no que nos guíen. Le echaba la culpa al sistema operativo, a la red… no quería verlo. Pero hablando con otros usuarios, a todos nos pasaba lo mismo… ¿de verdad es cosa tuya? ¿Tanta confianza tenemos?

Hoy me he hartado y me he instalado Opera. Ha sido un flechazo a primera vista. Tiene un sistema de marcado rápido muy amigable, es rápido, se lleva mucho mejor que tú con Java y Flash, tiene el recargar cada N segundos, contigo necesitaba el plugin ReloadEvery… No te perderé de vista, te actualizaré, con la esperanza de que vuelvas. No te desinstalaré, todavía te respeto. Pero…

Los usuarios somos así: nos sorprendemos rápido, nos enamoramos, pero no puedes fallarnos: tenemos tendencia a ser infieles.

Hace varios meses me enfrenté al primer desarrollo de un plugin Maven para generar un report en el site, y comprobé en mis carnes que había muy muy poca documentación, y en castellano era totalmente inexistente. Por ello considero interesante describir paso a paso el proceso para desarrollar un plugin sencillo del tipo Hola Mundo!, dejando para un post futuro otros detalles interesantes, como la utilización de ficheros properties, introducción de parámetros de configuración, generación de ficheros externos al report, etc.

Este post supone que el lector ya está suficientemente familiarizado con la utilización de Maven, por lo que no entraré en detalles excesivamente básicos, como explicar lo que es un pom.xml, cómo se utiliza Maven, etc. Lo único básico que explicaré es que un plugin Maven Report sirve para generar un informe que se anexa al site del proyecto (se invoca, por ejemplo, ejecutando ‘mvn site’) siempre que esté referenciado en el pom.xml del proyecto llamante, dentro de <reporting><plugins>. El propio site de Maven ya embebe varios plugins Report como el de dependencias.

Con esta sencilla introducción, vamos al lío: lo primero, un plugin report es un proyecto Maven, por lo que tiene su pom.xml y su directorio /src/main/java. Veamos cómo sería nuestro pom.xml:

<?xml version="1.0" encoding="UTF-8"?><project>
<modelVersion>4.0.0</modelVersion>
<groupId>com.viavansi</groupId>
<artifactId>report-plugin-demo</artifactId>
<packaging>maven-plugin</packaging>
<version>0.0.1</version>
<name>Plugin demo Report</name>
<inceptionYear>2008</inceptionYear>
<url>http://www.viavansi.com</url>
<organization>
<name>Servicios Avanzados para las Instituciones S.L. (VIAVANSI )</name>
<url>http://www.viavansi.com</url>
</organization>
<dependencies>
<dependency>
<groupId>org.apache.maven</groupId>
<artifactId>maven-project</artifactId>
<version>2.0</version>
</dependency>
<dependency>
<groupId>org.apache.maven</groupId>
<artifactId>maven-plugin-api</artifactId>
<version>2.0</version>
</dependency>
<dependency>
<groupId>org.apache.maven.reporting</groupId>
<artifactId>maven-reporting-api</artifactId>
<version>2.0</version>
</dependency>
<dependency>
<groupId>org.apache.maven.reporting</groupId>
<artifactId>maven-reporting-impl</artifactId>
<version>2.0.2</version>
</dependency>
</dependencies>
</project>


He marcado en negrita los puntos clave: por un lado, debemos indicarle a Maven que este proyecto es un plugin mediante la etiqueta <packaging>, y además declaramos las dependencias a los APIs de construcción de plugins y reporting de Maven.

Una vez creado nuestro fichero pom.xml, estamos en disposición de crear la clase del plugin en el paquete que deseemos, obviamente dentro de /src/main/java.

Un plugin report debe extender de la clase org.apache.maven.reporting.AbstractMavenReport, lo cual obliga a sobrescribir los siguientes métodos:

• protected String getOutputDirectory(): devuelve el directorio donde se generará el fichero HTML del report
• protected MavenProject getProject(): devuelve una referencia objetual al pom.xml del proyecto padre que llama al report
• protected Renderer getSiteRenderer(): devuelve la instancia del objeto que rendea el site Maven
• public String getDescription(Locale locale): devuelve la descripción del plugin, permitiendo internacionalización en función del Locale.
• public String getName(Locale locale): devuelve el nombre del plugin, permitiendo internacionalización en función del Locale.
• public String getOutputName(): devuelve el nombre del fichero HTML que se va a generar.
• protected void executeReport(Locale locale): esta es la madre del cordero, es el método que se invoca para generar el informe.

Para implementar los 3 primeros métodos, es interesante saber que Maven entregará a nuestra clase 3 objetos:

• Una instancia de Renderer
• Una instancia de MavenProject
• Una instancia de File, que se corresponde con el directorio de salida por defecto (el /target/site)

De forma que los utilizaremos para implementar esos 3 métodos. Para que Maven nos entregue esas 3 instancias, deberemos declarar esos 3 atributos de la clase y utilizar Annotations. Veremos esto al incluir el código entero de la clase.

Otro punto clave es que es obligatorio incluir un goal Maven a cada plugin, con una anotación @goal.

Y un último concepto de importancia es cómo escribir el HTML. Para ello se hace uso del API Sink perteneciente al proyecto Doxia. Utilizando el método getSink() obtenemos el objeto Sink que nos permite escribir información al informe.

Veamos el código Java del plugin. He marcado en negrita algunas de las líneas clave, siguiendo las instrucciones que he comentado anteriormente. El código está comentado para explicar paso por paso lo que es está haciendo:

package com.viavansi.maven.report;

import java.io.File;
import java.util.Locale;

import org.apache.maven.doxia.siterenderer.Renderer;
import org.apache.maven.project.MavenProject;
import org.apache.maven.reporting.AbstractMavenReport;
import org.apache.maven.reporting.MavenReportException;
import org.codehaus.doxia.sink.Sink;

/**
 * Genera un Hola Mundo en un site
 * @goal demo
 */

public class DemoMojo extends AbstractMavenReport {

    /**
     * Directorio donde se generará este report
     *
     * @parameter expression="${project.reporting.outputDirectory}"
     * @required
     */
        private File outputDirectory;

    /**
     * Maven nos pasa este valor, no debemos configurarlo.
     *
     * @component
     */
    private Renderer siteRenderer;

    /**
     * Instancia del proyecto (pom) que nos llamará.
     * De aquí se puede sacar cualquier información del pom.
     *
     * Maven nos pasa este valor, no debemos configurarlo.
     *
     * @parameter expression="${project}"
     * @required
     * @readonly
     */
    private MavenProject project;       

        @Override
        protected String getOutputDirectory() {
                return this.outputDirectory.getAbsolutePath();
        }

        @Override
        protected MavenProject getProject() {
                return this.project;
        }

        @Override
        protected Renderer getSiteRenderer() {
                return this.siteRenderer;
        }

        public String getDescription(Locale locale) {
                return "Nuestro primer plugin Maven Report";
        }

        public String getName(Locale locale) {
                return "DemoMavenReport";
        }

        public String getOutputName() {
                return "demo";
        }

        @Override
        protected void executeReport(Locale locale) throws MavenReportException {
                //Ejemplo de log en consola
                getLog().info("Iniciando plugin Demo");

                //Hago las tareas que deba hacer, lo lógico sería delegar la responsabilidad

                //Recupero el API Sink de Doxia para "pintar" resultados
                Sink sink = (Sink)getSink();

                //Cabecera del report
        sink.head();
        sink.title();
        sink.text("Nuestro primer Report Maven");
        sink.title_();
        sink.head_();    //Se cierran las maquetaciones de forma similar a HTML    

        //Cuerpo del report
        sink.body();
        sink.section1();
        sink.sectionTitle1();
        sink.text( "Apartado 1" );
        sink.sectionTitle1_();
        sink.paragraph();

        sink.text("Hola Mundo!");
        sink.lineBreak();

        //Ejemplo de utilización de información del pom del proyecto que llama
        sink.text("Detectamos en el pom: "
                        +project.getGroupId()+"."+project.getArtifactId()+"-"+project.getVersion());

        sink.paragraph_();
        sink.section1_();

        sink.body_();

        }       

}

Y listo. Para probar nuestro plugin, simplemente podríamos instalarlo en nuestro repositorio local (mvn install) o desplegarlo en algún repositorio de librerías, y referenciarlo desde otro proyecto Maven, en el apartado <reporting><plugins>…</plugins></reporting>. Veremos cómo se agregará nuestro report al site generado.

En un siguiente post mostraremos cómo podemos añadir características avanzadas a nuestros reports. Hasta entonces, feliz año a todos.

Con visión retrospectiva podemos ver que muchas de las bases sobre las que se sustentaba J2EE fueron un error.

En los primeros días de J2EE, los xmls eran vistos como el Santo Grial de la configuración, el framework estaba pensado para que todo se pudiera y tuviese que configurar en un xml, incluyendo nombres de clases java y métodos. Esta técnica que sobre el papel parecía ideal para ayudar al desacoplamiento del sistemas tenía consecuencias nefastas en el desarrollo.

La configuración en ficheros xml resultó ser muy repetitiva, propensa a errores (muy difíciles de encontrar en tiempo de ejecución) y en definitiva demasiado compleja para el programador medio.

Ahora, mirando hacia atrás podemos ver que no solo el propio J2EE, sino también otros frameworks como Hibernate, Struts, Spring, iBatis, etc… cometieron el mismo error, y poco a poco la plataforma Java se ha ido haciendo cada vez más y más compleja, hasta ser considerada por algunos como un dinosaurio inmanejable, con una dura curva de aprendizaje.

Esta situación, conocida como “El infierno XML“, la han aprovechado muy bien otros lenguajes como Ruby on Rails con su lema programación por convención, que precisamente evita la trampa en la que cayó J2EE.

Por suerte la comunidad Java ha reconocido el problema del abuso de XMLs y ha actuado remplazando parcialmente los ficheros XML con una mezcla de anotaciones en el código y convenciones establecidas que sólo requieren la configuración de los casos excepcionales.

Como respuesta a estos y otros problemas, han empezado a aparecer algunas soluciones como por ejemplo:

* EJB3/JPA: Que simplifica dramáticamente el engorro que actualmente suponía trabajar con EJBs 2.0 o Hibernate y que desde hace un año forma parte de todas nuestras aplicaciones con unos resultados excelentes.

* Seam: Un framework ligero para Java EE 5.0 que simplifica el desarrollo de aplicaciones web y que despues de algunos proyectos internos, se convierte este año 2008 en nuestro framework base para todos nuestros nuevos proyectos web.

* Web Beans (JSR 299): La gran esperanza que parte del camino iniciado por Seam y que pretende convertirse, al igual que ya pasó con JPA, en el estándar para comunicar la capa web con los EJBs.

* Grails: Que ha resultado muy ilusionate en las pruebas y quizás en el futuro se convierta tambien en compañero de viaje.

* JAX-WS 2.x: Que simplifica enormemente tanto la publicación como el consumo de Servicios Web. Después de años utilizando Axis, JAX-WS pasa a convertirse en nuestra pila Web services preferida.

En definitiva, aunque los XMLs seguiran siendo parte esencial de nuestro día a día, un nuevo camino se abre en los paradigmas de programación Java, …