Blog de Antonio Manuel Muñiz

Desarrollo, Ingeniería y Calidad del Software

Archivos en la Categoría: Herramientas

Análisis de un proyecto web Java y Javascript en Sonar

Actualmente existen plugins de Sonar para analizar código Javascript en Sonar, pero hay una limitación, y es que los proyectos en Sonar tienen un lenguaje determinado, por ejemplo, no podemos analizar un proyecto Java y Javascript al mismo tiempo. La única solución (hasta que Sonar permita el análisis de proyectos multi-lenguaje) es crear dos proyectos en Sonar usando el concepto de branch, y configurando dos análisis, uno para el código Java y otro para el código Javascript.

Si el proyecto está modelado con Maven podemos hacer uso de perfiles para definir las dos tareas. Para ello crearemos el siguiente perfil (suponiendo que el código Javascript se encuentre en src/main/webapp/ui):

<profile>
    <id>js</id>
    <build>
        <plugins>
            <plugin>
                <groupId>org.codehaus.mojo</groupId>
                <artifactId>build-helper-maven-plugin</artifactId>
                <executions>
                    <execution>
                        <phase>process-resources</phase>
                        <goals>
                            <goal>add-source</goal>
                        </goals>
                        <configuration>
                            <sources>
                                <source>src/main/webapp/ui</source>
                            </sources>
                        </configuration>
                    </execution>
                </executions>
            </plugin>
        </plugins>
    </build>
</profile>

Y lanzaremos dos análisis en Sonar, uno para analizar el código Java:

mvn clean install sonar:sonar -Dsonar.branch=Java

Y otro para analizar el código Javascript:

mvn clean install sonar:sonar -Pjs -Dsonar.branch=Javascript -Dsonar.language=js -Dsonar.dynamicAnalysis=false

Previamente es necesario instalar el plugin de análisis de código Javascript en Sonar (es cuestión de minutos usando el update center). El resultado serán dos proyectos en Sonar. Lo ideal sería un sólo proyecto, pero hasta que Sonar soporte proyectos multi-lenguaje es la única solución.

En la instancia de Clinker que usamos en klicap puedes ver un ejemplo de proyecto Javascript en Sonar.

Anuncios

Sonar PDF Report 0.3 en la GUI de Sonar

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

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

Migración desde Apache Archiva a Nexus

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

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

Override local storage

Monitorización remota en Java: JConsole

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 Dashboard

JConsole Memory

JConsole Memory

JConsole Classes

JConsole Classes

JConsole Summary

JConsole Summary

Sonar PDF Plugin 0.2 Released

Hace unos días hemos publicado Sonar PDF Plugin 0.2. Los cambios principales son: compatibilidad con Sonar 1.9, uso de “-Dbranch” e inclusión de hotspots en el reporte.

La publicación de esta nueva versión ha coincidido con la inclusión de Sonar en el Marco de Desarrollo de la Junta de Andalucía (proyecto MADEJA) como herramienta de verificación de la calidad del código de las aplicaciones desarrolladas para la administración pública andaluza.