Xnoccio.com

Hola a todos,

supongo que todos conoceis la fabulosa funcionalidad que tiene Redmine respecto al acceso a un sistema de control de versiones de código fuente, como el caso que nos ocupa: Subversion. Permite consultar las diferentes revisiones, mostrando los distintos comentarios de cada revisión, permite acceder a la estructura en árbol de directorios, etc…

En la situación que os quiero comentar teníamos una instalación de Redmine totalmente funcional, con la conexión a Subversion funcionando a las mil maravillas, vía https. Sin embargo de un día para otro dentro de la pestaña “Repositorio” del proyecto dejamos de ver la estructura de carpetas y ya no se actualizan la información acerca de las sucesivas revisiones que se iban generando en el repositorio, pero sí se veían otras revisiones anteriores.

El primer paso fue mirar en el log de Redmine y se comprobó que se estaba generando un error bastante “inquietante”:

Error parsing svn output: #<REXML::ParseException: No close tag for /lists/list>
…./jruby/lib/ruby/1.8/rexml/parsers/treeparser.rb:27:in `parse’
…./jruby/lib/ruby/1.8/rexml/document.rb:204:in `build’
………………….
………………….

Tras esto, nos conectamos con un cliente subversion y comprobamos que el repositorio estaba totalmente operativo y las revisiones se estaban generando correctamente (incluso con los respectivos comentarios): ¿qué podrá estar pasando? (si quereis ir directo a la solución sólo id al final del post xD)

Como suele ser muy habitual investigamos acerca de la conexión https que se establece con Subversión, ya que en este caso Subversion se sirve vía https. Pues bien, nos dimos cuenta que el certificado del servidor (el que sirve Subversion)  estaba caducado: ¡¡ Eureka !!

Para solucionar esto simplemente actualizamos el certificado del servidor Subversion y volvimos a intentar de nuevo consultar la pestaña Repositorio de Redmine, pero no… sigue el mismo problema, no se actualizan las revisiones.

Tras poner nuestras neuronas a trabajar nos dimos cuenta que no habíamos introducido el nuevo certificado como “confiable” para Redmine… muy bien, pero ¿cómo hacer esto? Para explicar esto voy a comentar cómo Redmine se conecta con Subversion y obtiene toda esa metainformación que muestra (esto lo podemos ver en el código fuente de Subversion.rb correspondiente al adaptador de Subversion que tiene Redmine):

Redmine no hace más que ejecutar la orden “svn –xml list <url_repositorio>” y esto devuelve (o debería) un XML con toda la información, algo tan simple como eso ¿cómo puede dar problemas?

Nos disponemos a ejecutar esa misma orden de forma manual desde la máquina donde tenemos instalado Subversion y ¡sorpresa!: no nos retorna un XML correcto. A continuación, ejecutamos un simple comando de listado “svn list <url_repositorio>” y obtenemos un mensaje de aviso, preguntándonos si deseamos rechazar / aceptar de forma permanente o temporal el certificado de https://servidorSubversion . Por supuesto lo aceptamos de forma permanente (pulsando ‘P’)  y a continuación nos pidela contraseña del usuario logado en el sistema y usuario/contraseña de acceso a Subversion.

A partir de ahí todo debería funcionar, pero no: hay un pequeño detalle más. Debemos repetir el paso anterior ejecutando el comando “svn”con el mismo usuario que hace correr el servicio de Redmine. Parece que el cliente svn tiene un almacen de certificados “confiables” distinto para cada usuario que lo ejecuta.

Una vez hecho todo esto nuestro Redmine se conecta perfectamente con Subversion y obtiene toda la información actualizada.

SOLUCION.- A continuación os resumo la solución con un par de pasos que se deben seguir, espero que os resulten útiles.

1. Ejecutar por consola el comando “svn list <url_subversion>” en la máquina en que corre Redmine y con el mismo usuario que hace correr el servicio.
2. En el diálogo que se muestra: aceptar el certificado como confiable de manera permanente (‘P’) e introducir los uusuarios/contraseñas que se solicitan.
3. Ejecutar por consola el comando “svn –xml list <url_subversion>” y comprobar ahora que sí nos devuelve un XML con todos los metadatos.
4. Comprobar que Redmine nos muestra ahora los datos correctos.

Versión de Redmine utilizada: Redmine 0.8.0.stable

Personalmente creo que este tipo de “errores” se deberían reportar de forma automática por parte de Redmine (mostrando una información más intuitiva) y es de esperar que en futuras versiones tomen en cuenta todos las numerosas incidencias que podeis ver en el bugtracker del proyecto Redmine respecto a este error.

Un Saludo a todos.
Namaste y buena suerte.

Por compatibilidad y por deseo de la mayoría de nuestros clientes, prácticamente todos nuestros proyectos Java han sido desarrollados con la versión Java SE 5 en mente. Pero esperamos que esta situación cambie este Otoño, ya que el soporte estándar para Java 5 termina el 30 de Octubre de 2009.
Después de esta fecha la versión 5 podremos considerarla deprectad, y aunque será posible contratar servicios de soporte Business a Sun, lo razonable será que el grueso de nuestros clientes por fin realicen la migración a Java 6 (que por cierto ya tiene unos añitos).

El único punto débil para realizar por fin esta deseada migración la tendremos con los clientes que quedarán anclados a la versión 5, de forma voluntaria u obligatoria, como por ejemplo los que usan la implementación Java de IBM para AIX ya que en este caso ni siquiera existe la JVM para Java 6.

Más información en http://java.sun.com/products/archive/eol.policy.html

Dice la competencia que después de la fusión entre Sun y Oracle tal vez el nuevo logo de Java EE vaya a ser como el que sigue:

Introducción

Mylyn-Mantis es un plugin que permite la integración en Eclipse con repositorios Mantis, de forma que se puede interactuar con un bugtracker Mantis directamente desde nuestro IDE, permitiendo:

• Crear incidencias
• Asignar incidencias
• Añadir comentarios
• Cambiar de estado incidencias
• Resolver incidencias
• Asociar un conjunto de código a una incidencia, a la hora de realizar un commit de código.

Utilización

Una vez que disponemos de un repositorio Mantis, podremos recuperar el conjunto de tareas de un proyecto, planificarlas, asignarlas, resolverlas, incorporar comentarios, asociar código fuente a las mismas…

Conexión a un repositorio

Gracias a Mylyn disponemos de dos nuevas vistas de interés:

• Task Repositories: en esta vista configuramos los distintos repositorios (por ejemplo, un servidor de Mantis) que almacenan proyectos/tareas.
• Task List: almacena tareas categorizadas de distintas formas (por ejemplo por proyectos).

Y como hemos dicho, gracias al plugin Mylyn-Mantis podemos utilizar Mantis dentro de Mylyn. Estas 2 vistas aparecen en la perspectiva “Planning”, perspectiva recomendada para trabajar con tareas.

En primer lugar deberíamos configurar el repositorio Mantis. Para ello necesitamos la vista Task Repositories. Esta vista podemos añadirla, si no la tenemos en nuestra perspectiva, a través de Window->Show View->Other, y desplegando la opción Mylyn. Dentro de esta vista, al hacer clic en el botón derecho del ratón nos aparece, entre otras, la opción de crear un nuevo repositorio de tareas (Add Task Repository):

Al escoger esta opción se nos solicita qué tipo de servidor queremos configurar. En el caso de Mantis escogeremos dicha opción:

Y se nos piden datos sobre el servidor de Mantis:

Deberemos conocer la URL del servicio SOAP de Mantis (Mantis-Connect), así como nuestro usuario y contraseña. En esta ventana podemos realizar una validación de la configuración, para comprobar que sea correcta antes de grabar. Una vez hayamos hecho esta comprobación, ya disponemos de una conexión a Mantis.

Consulta a un repositorio y descarga de incidencias

Para ello creamos una query al repositorio Mantis. Dentro de la vista Task List, botón derecho del ratón, escogemos la opción “New Query”:

Escogeremos nuestro repositorio de tareas (Mantis) y continuamos. Le damos un título al filtro (normalmente el del proyecto con el que estemos trabajando) y en el desplegable escogemos el proyecto y un filtro. Estos filtros son queries que deben haber sido definidas previamente; es necesario disponer de al menos un filtro definido en Mantis, ya sea público o privado (un usuario, tras hacer una búsqueda avanzada, puede guardar ese filtro y recuperarlo en este momento; por ejemplo, puede crearse un filtro para recuperar sólo las incidencias no resueltas asignadas a él).

Al grabar se nos crea esta consulta, y el plugin comienza un proceso de sincronización con el servidor Mantis para descargarse todas las incidencias que cumplan el filtro:

En cualquier momento podemos crear una nueva tarea dentro de Eclipse. Para ello, simplemente tenemos que invocar a New Task dentro de la vista Task List

Para crearla, nos pedirá primero en qué repositorio de tareas queremos grabarla (Mantis), luego pide el proyecto y se pulsa en Finish. Se llega a una ficha de la tarea donde podremos grabar sus datos. Esta ficha es idéntica a la que se observa al acceder al detalle de una tarea, donde podemos realizar prácticamente cualquier actividad sobre ella: cambiar su estado, asignación, dar comentarios, etc.

Trabajando con tareas

Como se ha comentado, se recomienda el uso de la perspectiva Planning En la ficha de una tarea (parte superior derecha) disponemos de una opción para Activar / Desactivar una tarea:

Al activar una tarea, le indicamos a Eclipse que todo el código que incluyamos hasta el momento se corresponde con esa tarea, asociando el mismo al contexto de dicha tarea.

Si volvemos a nuestra perspectiva de trabajo (por ejemplo Java o Java EE, vista Project Explorer) es posible que dejemos de ver nuestros ficheros, advirtiendo un mensaje “Empty task context, unfocus or Alt + click”. Esto es debido a que Eclipse incorpora la posibilidad de filtrar nuestros proyectos/ficheros viendo sólo aquellos que están incluidos (relacionados) en el contexto de la tarea seleccionada:

Simplemente pulsando sobre el icono de filtrado volveremos a ver todos los proyectos y ficheros, sin filtrar por el contexto de una tarea.

Esto por ejemplo provoca que se genere un comentario específico a la hora de hacer commit del conjunto de ficheros asociados al contexto de una tarea, muy útil para conocer qué tarea se ha resuelto con el conjunto de código entregado:

Planificando tareas

Eclipse nos permitirá planificar nuestras tareas asignadas en fechas, y nos avisará en pantalla en el momento en el que se supone que deberíamos desarrollar una tarea concreta.

* Sólo Chuck Norris puede hacer una clase  abstracta y final.
* Chuck Norris serializa los objetos directamente en cráneos humanos.
* Chuck Norris no despliega aplicaciones web, él las mete a patadas en el servidor.
* Chuck Norris siempre utiliza sus propios patrones de diseño, y su favorito es la Patada Voladora Chuck.
* Chuck Norris puede usar para matarte cualquier clase de java.util .* , incluido el javadocs.
* Chuck Norris puede golpear tan fuerte que tu aplicación web se convierta en una aplicación swing, y es muy probable que sea una aplicación swing con una gran cantidad de iconos de cráneos humanos.
* Chuck Norris demostró el significado de Float.POSITIVE_INFINITY contando hasta él, dos veces.
* La sincronización no protege frente a Chuck Norris, si quiere el objeto, él lo toma.
* Chuck Norris no usa javac, él edita directamente los .class con un editor binario.
* El código Java de Chuck Norris nunca necesita ser optimizado. Su código es tan rápido que rompió la velocidad de la luz durante una prueba en los laboratorios de Sun matando a 37 personas.
* Cuando alguien intenta utilizar un método deprecated hecho por Chuck Norris , el método no avisa de que está deprecado. Automáticamente te pega una patada voladora en la cara en tiempo de compilación.
* El paquete java.lang originalmente contenía una ChuckNorris clase, pero fue quitado del paquete durante la revisión ya que Bill Joy recibió una patada voladora en la cara.
* Chuck Norris no tiene un error en su código, EVER!
* Chuck Norris no escribe código. Él mira a la pantalla de un ordenador hasta que obtiene el PROGRAMA que quiere.
* El código funciona más rápido cuando Chuck Norris lo mira.
* Chuck Norris modifica binarios .class ignorando el verificador de bycodes de Java.
* Chuck Norris no captura excepciones porque nadie tiene el coraje para lanzar ninguna.
* Chuck Norris puede hacer un casting a cualquier objeto sólo mirándolo.
* Si usted recibe un ChuckNorrisException lo más probable es que muera.
* Chuck Norris es el único que puede utilizar GOTO y const en Java.
* Chuck Norris puede compilar el código Java en . NET Framework, evidentemente, sólo mirándolo.
* Chuck no necesita capturar ninguna excepción de Java porque cuando va a lanzar la excepción Java tiene miedo de su patada voladora.
* Los niveles de visibilida Java son public,default, protected, private y protected By Chuck Norris “, no intente tener acceso a un campo con este último modificador!
* Chuck Norris come crudos JavaBeans y da patadas voladoras a JavaServer Faces!
* Chuck Norris puede dividir por 0!
* Recolector de basura sólo se ejecuta sobre el código de Chuck Norris para recoger los cadáveres.
* Cada línea de código de Chuck Norris se ejecuta en tiempo real. Incluso en una aplicación multi-thread.
* Cuando una CRU carga un .class de Chuck Norris duplica la velocidad.
* Chuck Norris puede ejecutar instrucciones de 64 bits en una CPU de 32 bits.
* Chuck Norris implementa “Indestructible”. Todas las demás criaturas implementan “Killable”.
* Chuck Norris sólo programa aplicaciones web en Java para conseguir ganar el .WAR!
* Chuck Norris dio una vez una patada voladora a una clase Java. El resultado es conocido como las inner class.
* Chuck Norris puede hacer herencia múltiple en Java.
* JVM no arroja excepciones a Chuck Norris, ya no. Que matara a 753 ingenieros de Sun fue suficiente.
* Chuck Norris no necesita unidad de pruebas, porque su código siempre funciona. Siempre.
* Chuck Norris extiende a Dios. ( Y Dios que era final no pudo hacer nada para evitarlo)
* Chuck Norris tiene tanta memoria de trabajo y es tan poderoso que puede ejecutar todas las aplicaciones Java en el mundo y obtener el 2% de uso de los recursos.
* Chuck Norris ya usaba en su código genéricos en la versión 1.3.
* Una clase Chuck Norris no puede ser decompilada… no se moleste en intentarlo.

Traducción libre de: http://www.ovisual.com/4/

Este artículo pretende ser una guía rápida qué explique cómo realizar una operación de autenticación con Viafirma, de cara a obtener los datos del certificado digital del usuario.

Aunque Viafirma ofrece todos sus servicios mediante métodos estándar (Servicios Web y OpenID), también disponemos  de un cliente para Java que permite de una forma muy sencilla integrar aplicaciones desarrolladas en esta tecnología con los servicios que ofrece Viafirma.

En este artículo mostraremos cómo añadir las dependencias necesarias a un proyecto web Java para hacer uso de los diferentes servicios de firma digital (XAdES, Facturae, PDF sign, etc… ), autenticación (FNMT, Camerfirma, Firma profesional, Ancert, ACA, Izempe,  DNIe, etc…),  custodia (integridad, etc…)  y verificación (CRLS, OCSP, etc…).

El procedimiento sería el siguiente:

1.- Añadir las dependencias

Viafirma está preparado para trabajar con Maven; en este tipo de proyectos sólo será necesario añadir la dependencia a viafirma-client de la siguiente manera:

<!--  Dependencias para el cliente viafirma con soporte de OpenID -->
<dependency>
 <groupId>org.viafirma</groupId>
 <artifactId>viafirma-client</artifactId>
 <version>[2.2.3,2.3.0)</version>
</dependency>

Y poner el repositorio de librerías de VIAVANSI para poder recuperar esta librería:

http://repositorio.viavansi.com/repo

Si el proyecto no está basado en Maven, necesitaremos añadir manualmente los .jar que se incluyen en el directorio dependency dentro del distribuible de viafirma-client.

2.- Crear la página de acceso a la autenticación

A modo de ejemplo básico vamos a crear una jsp que inicialice el cliente de Viafirma y permite al usuario iniciar el proceso de autenticación pulsando en un enlace. Este cliente utilizará el servidor público de pruebas de Viafirma desplegado en las instalaciones de Viavansi.

<%@page import="org.viafirma.cliente.ViafirmaClientFactory"%>
<%@page import="org.viafirma.cliente.ViafirmaClient"%>
<body>
<%
if (!ViafirmaClientFactory.isInit()) {
 // Configuración básica del cliente.
 ViafirmaClientFactory.init("http://viafirma.viavansi.com/viafirma","http://viafirma.viavansi.com/viafirma");
}
if(request.getParameter("autenticar")!= null){
 ViafirmaClient viafirmaClient = ViafirmaClientFactory.getInstance();
  // Iniciamos la autenticación indicando la uri de retorno. 
 viafirmaClient.solicitarAutenticacion(request, response,"/viafirmaClientResponseServlet"); }
%>
<p><a href="?autenticar=true">Solicitar autenticación</a></p>
</body>

Cuando el usuario pulse sobre el enlace “Solicitar autenticación” el usuario será redirigido a Viafirma, donde se le solicitará su certificado digital. Viafirma validará y tratará el certificado del cliente y retornará el resultado de la autenticación a la aplicación cliente que estamos desarrollando. En la jsp de ejemplo le indicamos a Viafirma que la url de retorno (donde Viafirma debe mandarnos el resultado de la autenticación) es /viafirmaClientResponseServlet .

3.- Procesar la respuesta

Una vez que Viafirma obtenga la información contenida en el certificado digital, retornará los datos a la url que la aplicación cliente le indicó, por lo que el siguiente paso será definir un servlet (cuya URL en este ejemplo es /viafirmaClientResponseServlet) que se encargue de gestionar la respuesta. Para ello crearemos un servlet que extiende de org.viafirma.client.ViafirmaClientServlet, e implementaremos los métodos error(…), cancel(…) y authenticateOK(…):

public class ViafirmaClientResponseServlet extends ViafirmaClientServlet{
 @Override
 public void authenticateOK(UsuarioGenericoViafirma usuario,HttpServletRequest request, HttpServletResponse response) {
  // Lógica específica de la aplicación para gestionar el resultado de la autenticación 
  request.setAttribute("usuarioAutenticado", usuario);
  request.getRequestDispatcher("/resultadoAutenticacion.jsp").forward(request, response);
 }
 @Override
 public void cancel(HttpServletRequest request, HttpServletResponse response) {
   // Gestiónn de cancelaciónn del usuario al autenticar o firmar
   request.setAttribute("error", "El usuario ha cancelado la autenticación");
   request.getRequestDispatcher("/resultadoAutenticacion.jsp").forward(request, response);
 }
@Override
public void error(CodigoError codError, HttpServletRequest request, HttpServletResponse response) {
  // Gestión de error al autenticar o firmar 
  request.setAttribute("codError", codError); 
 request.getRequestDispatcher("/resultadoAutenticacion.jsp").forward(request, response);
 }
}

En este ejemplo vemos un ejemplo de implementación, en el que la aplicación simplemente guarda en request el objeto UsuarioGenericoViafirma que contiene todos los datos que aparecen en el certificado digital. Obviamente cada aplicación, en función de su lógica de negocio, deberá realizar la implementación específica que requiera.

4.- Adaptar la plataforma al skin de la aplicación cliente.

La página donde se solicita el certificado digital reside en Viafirma. Sin embargo, a través de CSS podremos conseguir que el usuario no aprecie un cambio de interfaz, de forma que el salto de la aplicación a Viafirma parezca transparente a nivel estético.

Para hacer que Viafirma se adapte fácilmente al estilo visual de nuestra aplicación cliente, sólo tendremos que colocar el fichero viafirmaStyle.css en el raíz de nuestra aplicación y redefinir el aspecto visual de la interfaz  de Viafirma.

5.- Descarga el cliente y pruébalo tu mismo

Descargar ejemplo de autenticación utilizando el cliente Java para obtener los datos del certificado digital.

Próximamente: Java / JEE : Firma digital XADES y facturae con Viafirma (II)

Los programadores se enfrentan a una paradoja de valores básicos. Todos los desarrolladores con algunos años de experiencia saben que desordenes previos son causas de retraso. Y sin embargo todos los desarrolladores sienten que la presión les hace dejar mal algunas cosas para conseguir alcanzar las fechas de entrega. En resumen, no se toman el tiempo necesario para ir rápido.

Los verdaderos profesionales saben que la segunda parte de la paradoja está mal. No llegarás a la fecha haciendo mal las cosas. Es más, hacer las cosas mal te retrasará instantáneamente, y te forzará a incumplir la fecha de entrega. La única manera de llegar a la fecha -la única manera de ir rápido- es mantener el código tan limpio como sea posible durante todo el tiempo.

Parrafos del libro “Clean Code”,  leido en el blog de José Manuel Beas

Para comprobar el rendimiento de nuestra plataforma de firma, hemos realizado una serie de pruebas de estrés sobre el API Web Service de Viafirma. El objetivo de estas pruebas ha sido obtener métricas de comportamiento y limites de carga para los diferentes servicios ofrecidos, para determinar el rango de operaciones en los que el servicio es estable.

Para las pruebas se han realizado firmas en servidor XAdES de ficheros xml de 20k, utilizando como sistema de custodia ficheros y firmando con un certificado de Firma Profesional en software.

Se han realizado en dos tipos de entornos, el primero bastante precario en recursos y el segundo un entorno de producción real. En ambos casos pudimos comprobar que el comportamiento de Viafirma, ante un gran numero de peticiones fue más que aceptable.

Rendimiento de Viafirma con los requisitos Mínimos de Hardware

El entorno donde se realizaron las pruebas  es un portátil con un procesador Turion a 2 GHz y 2 gigas de RAM, con el servidor de aplicaciones  configurado para permitir 200 hilos concurrentes y con un máximo de 512 MB asignados.

Las pruebas se realizaron configurando un grupo de hilos simulando 100 peticiones por segundo en un bucle infinito.

A continuación se muestran los resultados obtenidos en la misma máquina y misma configuración en un entorno Windows y en un entorno Linux.

Pruebas sobre Windows XP SP 3 en JRE 6.0.11 de Sun

Como se observa en la gráfica, Viafirma mantuvo la cantidad constantes de 1.200 peticiones por minuto con una media de cerca de 5 segundos desde la entrada de la petición hasta su resolución y respuesta.  Mientras se realizaros las pruebas, Jconsole marcó en todo momento un consumo de memoria estable.

Pruebas sobre Ubuntu 8.10 en JRE 6.0.10 de Sun

Repetimos las pruebas en un entorno Unix, y observando que el rendimiento es algo mayor. Respondiendo una media de 2.100 peticiones por minuto.

Rendimiento de Viafirma con la configuración de Hardware recomendada

Después de haber hecho estas pruebas “de andar por casa”, hemos repetido la misma batería de pruebas sobre un entorno de producción, un  Ubuntu Server con 8 nucleos, 6 Gb de memoria y una configuración optimizada de la JVM 6.

Como podemos observar,  el comportamiento es excelente, alcanzando casi más de 7.500 firmas por minuto, manteniéndose totalmente estable la JVM y con el procesador nunca superando el 50% ( debido a los tiempos de espera impuestos por la red).

El algoritmo Haversine sirve para calcular la distancia entre dos puntos de los que conocemos su longitud y latitud. A continuación incluimos un método Java que implementa esta fórmula devolviendo la distancia en metros:

    private static int calculateDistanceByHaversineFormula(double lon1, double lat1,
double lon2, double lat2) {

return (int)distanceInMeters;

}

En nuestro caso ha sido utilizado para evaluar la distancia a un establecimiento determinado desde nuestra posición actual (calculada mediante GPS).

Apache Continuum

Continuum es una potente herramienta de Integración Continua desarrollada por Apache; su descarga está accesible en la URL: http://continuum.apache.org/download.html

• Instalación

La instalación de Continuum Server es sencilla; para una instalación básica basta con descargar el paquete de instalación apropiado de la web de Continuum, descomprimir el paquete en el directorio destino escogido y configurar las conexiones a base de datos a utilizar. Una vez instalado, para su ejecución solo se requiere lanzar uno de los scripts incluidos en el directorio bin.

Como hemos podido comprobar, la configuración básica es realmente sencilla, pero en la mayoría de los casos necesitaremos configurar conexiones a bases de datos, sistemas de correo, gestión de permisos avanzada, etc., además de desplegar Continuum sobre un servidor de aplicaciones. Para este tipo de configuraciones deberemos modificar los ficheros de configuración basados en xml o properties según el caso.

En términos generales la documentación del producto es buena, si bien resulta algo pobre. Esto suele ser tradicional en la mayoría de los proyectos del grupo Apache; existen algunos apartados con documentación muy completa, pero quedando otros aspectos de la documentación por terminar.

En Continuum nos enfrentamos a una curva de aprendizaje relativamente lenta para personal no especializado, debido a algunas configuraciones no documentadas y multitud de conceptos que hay que saber manejar desde el principio. Por ejemplo, se suele requerir adaptar el fichero continuum/conf/application.conf, o los ficheros pom.xml de los proyectos Maven de forma acorde a lo que espera Continuum.

• Administración, gestión de proyectos

Con esta herramienta muchas de las tareas administrativas podrán ser realizadas mediante la consola web. Aunque otras  tareas avanzadas requieran la modificación de ficheros de configuración.

La herramienta permite la definición de tareas periódicas desde su interfaz web de una forma sencilla, pudiendo automatizar tareas. Si bien la configuración de estas operaciones es sencilla, la documentación oficial al respecto es nula.

Respecto a las gestión de copias de seguridad, sólo se contempla un backup basado en un cliente xml-rpc, no existiendo documentación asociada a este cliente. Por otro lado, la opción alternativa se basa en realizar copias externas de la base de datos y los ficheros de trabajo, en función del tipo de instalación y base de datos utilizada.

Se puede destacar que no existe documentación en linea mientras se utiliza la herramienta. Ello, unido a la escasa documentación, provocó que durante nuestra evaluación tardásemos más tiempo del esperado en configurar nuestras primeros proyectos Maven sobre Continuum.

Continuum es un software en constante crecimiento, el cual ha mejorado mucho en las últimas versiones. Sin embargo, la actualización a nuevas versiones no resulta siempre directa; en la mayoría de los casos resulta necesario ejecutar alguna herramienta de migración para actualizar desde versiones anteriores.

• Seguridad

El sistema dispone de un mecanismo de seguridad muy completo, basado en usuarios, roles, y permisos sobre operaciones o proyectos, permitiéndonos la definición de una matriz completa de permisos. Sólo necesitaremos modificar el fichero de configuración security.properties cuando estemos realizando configuraciones avanzadas.

• Integración con sistemas externos

Apache Continuum no ofrece mecanismos de extensión o plugins, limitándose a permitirnos la llamada a plugins Maven desde los comandos de compilación asociados a los proyectos. Esto hace que dependa de la correcta configuración de plugins Maven report y build en los ficheros pom.xml de los proyectos gestionados.

Por este motivo, si requerimos que Continuum ejecute procesos de testeo, bugtrackers, validación de reglas de estilo, etc., necesitaremos definir éstos en el fichero pom.xml del proyecto. Sin embargo, no obtendremos una integración completa entre Continuum y los plugins Maven utilizados (Continuum lanza los procesos, pero no integra sus respuestas para plasmar los resultados en pantalla). Del mismo modo, la integración con el sistema de control de versiones dependerá de la correcta configuración del plugin SCM en el fichero pom.xml del proyecto gestionado.

Otro aspecto que se echa de menos es un mecanismo para despliegue de aplicaciones y librerías que sea independiente de la definición de estos mecanismos en Maven. Nuevamente se exige una correcta configuración de estos aspectos en el pom.xml del proyecto.

En general, esta parece una debilidad grave de Continuum, ya que depende en exceso de que los ficheros pom.xml estén perfectamente configurados, y por ello la realización de procesos de verificación es dependiente de la buena voluntad del desarrollador, no de las personas responsables de estas tareas (como gente de Desarrollo o de Calidad).

• Tipos de proyectos soportados

Apache Continuum está especialmente enfocado a proyectos Maven, si bien también ofrece soporte a proyectos con scripts Ant y otro tipo de proyectos sin formato basados en scripts de compilación. Aunque las limitaciones se podrían solventar mediante proyectos shell, se echa en falta la integración con otros lenguajes o mecanismos como ivy, rake, etc.

• Facilidad de uso

Nos encontramos ante una herramienta con una potente interfaz web, que utiliza un conjunto de iconos preestablecidos para indicar los estados y acciones disponibles, ofreciéndonos a su vez una leyenda para su fácil interpretación.

El único apartado negativo es que no aporta ayuda en línea sobre los diversos conceptos y elementos de la interfaz, por lo que es necesario un mínimo conocimiento previo de los conceptos tratados.

Respecto a la documentación oficial, ofrece una documentación muy escueta con multitud de apartados tan sólo esbozados, siendo por ello recomendable recurrir a artículos externos o libros especializados.

• Estabilidad

Estamos ante un software estable y fiable como la mayoría del software desarrollado por el grupo Apache. A continuación se detallan las últimas versiones liberadas de la plataforma:

Una buena prueba de estabilidad del software es que está siendo utilizado internamente por varios de los proyectos gestionados por la propia Apache.

Respecto al rendimiento, el principal defecto es que no dispone de gestión de hilos de compilación, ni de mecanismos para la compilación distribuida, aunque es posible ver el listado de tareas pendientes y detenerlas si se desea. La ausencia de aquellas opciones hace que en ocasiones se puedan causar picos de caída de rendimiento, o falta de adaptación a las prestaciones de estaciones multiprocesador.

• Conclusiones finales sobre Continuum

Apache Continuum es aún un producto relativamente joven con mucho espacio para crecer y mejorar. Ha avanzado en buena medida desde sus primeras versiones, las cuales no alcanzaban el nivel de calidad mínimo exigido a este tipo de soluciones. Sin embargo, las nuevas funcionalidades que han ido apareciendo en las últimas versiones, unido a su intuitiva consola de administración, lo hacen una buena herramienta y una opción seria para implementar una infraestructura de desarrollo basada en esta plataforma de Integración Continua.

Los principales puntos negativos encontrados han sido la falta de algunas funcionalidades típicas disponibles en otras soluciones de Integración Continua, donde destaca sin duda la inexistencia de un mecanismo de extensión de funcionalidad que permita la inyección de plugins. Continuum se basa al 100% en la configuración previa establecida en el pom.xml (reporting, checkstyle, scm, etc.), exigiendo así que la definición del proyectos sea completa para su correcto funcionamiento. Por decirlo de una forma reducida, ello implica que todos y cada uno de los proyectos deben disponer de la misma configuración, y si se desea ampliar una funcionalidad, ello implica la modificación del fichero pom.xml de todos los proyectos. Sin duda, Continuum adolece de una gestión centralizada de extensiones que permitiese configurar este tipo de funcionalidades a nivel plataforma, no a nivel proyecto.

• Comentario personal

Apache Continuum resultó un software genial durante el tiempo que estuvimos utilizándolo en los proyectos internos del departamento de I+D, pero causó demasiados problemas cuando comenzamos la migración de todos nuestros proyectos de desarrollo a un entorno de integración continua. Hay que aclarar que la mayoría de los problemas que encontramos no son directamente achacables a Continuum, sino a la poca experiencia con este tipo de soluciones del grupo de desarrolladores y a las exigencias que se imponían sobre proyectos que, por falta de tiempo, nunca eran configurados al 100%. Finalmente lo descartamos eligiendo una solución más sencilla en su manejo y con menos exigencias respecto a la configuración completa de los proyectos gestionados.

Continuación: LuntBuild. Eligiendo nuestro entorno de Integración Continua (III).