Desde ayer está disponible en el repositorio central de Maven Sonar PDF Plugin 0.3.
Como comentaba hace unos días, esta versión ofrece (además de un nuevo tipo de reporte) la posibilidad de usar Sonar PDF como un plugin propio de Sonar (hasta ahora sólo era posible usarlo como un plugin de Maven), configurable desde la propia GUI. La configuración se limita actualmente a la activación o desactivación del reporte.
Este plugin es el primero (en la forja de Sonar Plugins) que hace uso del concepto de “Sonar post-job”: acciones que se ejecutan como parte del ciclo definido por sonar:sonar una vez finalizado el análisis. Es decir, una vez instalado el plugin en Sonar, al ejecutar mvn sonar:sonar sobre uno de nuestros proyectos estaremos generando un reporte PDF al final del análisis (el reporte se almacena en el target de la copia de trabajo).
En la página del plugin hay disponible información más detallada en relación a la instalación, un enlace para la descarga directa de los binarios y características generales.
¿Qué hay previsto para la versión 0.4?
- Revisión del diseño de los reportes
- Inclusión de más opciones de configuración desde Sonar (por ejemplo, selección del tipo de reporte)
- Disponibilidad de descarga del reporte desde la interfaz gráfica de Sonar
Pero por ahora, disfrutemos de la versión 0.3 :)
Categorías: Maven Plugins · Open Source
Etiquetado: Sonar, Sonar PDF Plugin
A partir de la versión 0.3 de Sonar PDF Report (su publicación se realizará en los próximos días) se podrá configurar su uso desde la interfaz gráfica de Sonar.
Por ahora sólo podemos indicarle a Sonar que genere el reporte en PDF como parte del análisis, haciendo uso del concepto de “post-jobs” (a partir de la versión 1.10).
PDF Report en la GUI de Sonar
El siguiente paso será dotar a la interfaz de más posibilidades de configuración, como la selección del tipo de reporte, y por último la inserción del reporte en la base de datos para poder descargarlo desde el navegador, pero esto es el futuro… no muy lejano.
El proceso para instalar el plugin en Sonar es el estándar para todos los plugins, copiar el jar en el directorio de extensiones y reiniciar Sonar.
Me gustaría agradecer a Simon Brandhof la ayuda en la integración del plugin como “post-job”.
Categorías: Herramientas · Open Source
Etiquetado: PDF, Sonar, Sonar PDF Plugin
En estos días estamos renovando nuestro ecosistema, el primer habitante nuevo ha sido Nexus, posiblemente le sigan Hudson, nuevas versiones de Subversion, Trac y Sonar.
La migración de Archiva a Nexus ha sido realmente suave, del lado del “cliente” (Maven) el impacto ha sido simplemente el cambio de una URL en settings.xml, donde digo Archiva digo Nexus y listo.
Del lado del servidor la cosa no ha sido mucho más compleja. Nexus viene configurado perfectamente:
- Un repositorio interno de releases
- Un repositorio interno de snapshots
- Un grupo de repositorios de releases (incluye el interno, en central y el de codehaus)
- Un grupo de repositorios de snapshots (incluyendo el interno y el de codehaus)
Sólo había un pega, ¿qué pasa con los artefactos internos que tenemos desplegados en nuestro Archiva (lo que viene a ser nuestro proyecto Commons)? ¿y que pasa con los artefactos que hemos desplegado porque no se encuentran en ningún repositorio público (p.e. driver de Oracle)?
La solución ha sido mantener los dos repositorios (Archiva y Nexus) durante un tiempo y decirle a Nexus que haga mirror de Archiva.
Para ello hemos creado dos nuevos repositorios (releases y snapshots) de tipo “Proxy” en Nexus que apuntan a las URLs de nuestro Archiva.
New proxy repository
Hecho esto tenemos un proxy de Archiva en Nexus, pero la idea es poder eliminar (apagar) Archiva en unos días/semanas y deshabilitar los proxies que hemos creado en Nexus. Para poder borrar los proxies sin perder la “importación” de los artefactos debemos mapear el “local storage” de los proxies en los correspondientes repositorios internos (Archiva releases con Nexus Releases e idem para snapshots), en lugar de usar el valor por defecto.
Override local storage
Categorías: Herramientas
Etiquetado: Archiva, Maven repository, Nexus
Hoy ha sido uno de esos días en los que me doy cuenta lo mucho que me gusta mi trabajo.
Ha habido un momento en que me he visto a mi mismo, allí sentado, con dos portátiles delante, uno mostrándome 9 consolas recibiendo los datos de 9 load tests (cada uno modelando un caso de uso del sistema) ejecutandose simultáneamente. El otro mostrándome un conjunto de gráficas sobre el estado del servidor de aplicaciones, todo en tiempo real.
En la misma sala, 5 equipos controlados desde las consolas ejecutando las pruebas y reportando información.
Terminada la primera tanda, decidimos modificar algunas pruebas, lo hago en el equipo que tengo delante (en 3 de las consolas), automaticamente los 5 equipos controlados reciben los cambios, ya estamos preparados para la segunda tanda.
20 minutos, ese el tiempo que he dejado correr los test, ese el tiempo que he tenido para pensar (y disfrutar) del tinglado que teníamos allí montado.
El resultado, una prueba que ha sometido al sistema a una carga muy cercana a lo que sería la mitad de los usuarios potenciales accediendo simultáneamente, y que nos ha dado un conjunto de datos muy valiosos.
Y por si eso es poco, llego a la oficina y me encuentro una sala con las paredes empapeladas con prototipos de una aplicación y anotaciones a rotulador, tres de mis compañeros comentado algo sobre unos de los posters, les digo “¿qué ha pasado aquí?“, y me contestan “nada, una sesión de trabajo con el cliente“… !impresionante!
Pues eso, me gusta mi trabajo ;-)
Categorías: Miscelánea
Cuando ejecutamos pruebas de carga sobre una aplicación web en un entorno de producción nos enfrentamos a una serie de restricciones:
- No podemos ejecutar ninguna herramienta en el entorno de producción. Debemos limitarnos a tocar parte de la configuración.
- No tenemos interfaz gráfica
- Las condiciones del entorno son “las que son”, no hay posibildad de cambio.
Para la ejecución de las pruebas no hay demasiados problemas, accedemos a modo de cliente, con herramientas como Tsung (comentada aquí hace poco tiempo) o The Grinder (con la que estoy teniendo una estrecha relación ultimamente, y escribiré algo pronto).
Los problemas vienen a la hora de tomar datos de rendimiento de la JVM mientras ejecutamos el load-test, que dadas las condiciones anteriores debemos hacerlo de forma remota. Hay varias herramientas que nos pueden ayudar, como son VisualVM o JConsole (ambas distribuidas con JDK 6). Yo me he quedado con JConsole por una sola razón: en modo remoto me proporciona más información sobre la JVM que VisualVM (para monitorizar en local, no hay duda, VisualVM es la elección).
Para configurar el acceso remoto de JConsole se debe lanzar la máquina virtual a monitorizar con las opciones:
-Djava.rmi.server.hostname=192.168.0.12
-Dcom.sun.management.jmxremote
-Dcom.sun.management.jmxremote.port=9005
-Dcom.sun.management.jmxremote.authenticate=false
-Dcom.sun.management.jmxremote.ssl=false
Comprobamos desde la máquina cliente (la que usaremos para lanzar JConsole) que el puerto está abierto en la máquina objetivo (en el ejemplo 192.168.0.12):
Antonio$> nmap 192.168.0.12 -p 9005
Starting Nmap 4.53 ( http://insecure.org ) at 2009-06-14 21:26 CEST
Interesting ports on 192.168.0.12:
PORT STATE SERVICE
9005/tcp open unknown
NMap done: 1 IP address (1 host up) scanned in 0.144 seconds
Sólo queda iniciar JConsole:
Antonio$> jconsole 192.168.0.12:9005
JConsole monitoriza memoria, CPU, Threads y clases instanciadas, además muestra un dashboard muy útil:
JConsole Dashboard
JConsole Memory
JConsole Classes
JConsole Summary
Categorías: Herramientas · Java
