Planeta NetBeans

Avbravo: NetBeans 6.7 en Español

Mon, 29 Jun 2009 20:37:24 +0000

Ya esta disponible la versión final de NetBeans 6.7
Puedes descargarlo desde aqui

Quiero agradecer a todos los miembros del equipo de traducción en español por este esfuerzo realizado , realmente mis agradecimientos. Podemos decir que es un trabajo de la comunidad.

Ver las caracteristicas aqui

Programa en Java y disfruta de un café lojano » Java – Netbeans: JFormattedTextField y el método selectAll()

Sun, 28 Jun 2009 23:26:07 +0000

Una pregunta que nos hicieron en otro post era: ¿qué se debe hacer para que cuando un JFormattedTextField gane el foco se sobreescriba el texto que se muestra actualmente?

Mi primer respuesta fue programar el evento focusGained (cuándo gana el foco) e invoca al método selectAll() que permite seleccionar el texto que muestra el JFormattedTextField. En teoría funciona, pero resulta que no es así. La explicación es la siguiente:

Existe un bug, el 4740914, que ha sido reportado desde la versión 1.4 y que en breves palabras nos dice que existe un problema cuando se llama al método selectAll() de un JFormattedTextField.

La solución se muestra en el mismo reporte del bug. Y es la siguiente:

 private void
      jFormattedTextField1FocusGained(java.awt.event.FocusEvent evt) { SwingUtilities.invokeLater(new Runnable() { public void run() { jFormattedTextField1.selectAll(); } }); }

Básicamente lo que se hace es crear un hilo que llama al método selectAll sobre el JFormattedTextField. En mi caso lo programé en el método que maneja el evento focusGained. Existe una nota que dice: Please note that this solution does not work when this component is used as an editor in a JTable with surrender-focus enabled.

Espero que les ayude, en especial a quién hizo la pregunta.

Avbravo: NetBeans 6.7 RC3

Tue, 16 Jun 2009 17:30:44 +0000

Ya esta disponible la versión de NetBeans 6.7 RC3, Diego Silva miembro del equipo de traducción comenta al respecto en su blog.

Avbravo: Bugzilla desde NetBeans 6.7

Tue, 16 Jun 2009 17:28:06 +0000

Nuestro amigo Diego Silva, continua con nuestra serie blogs acerca de las caracteristicas de NetBeans. 6.7, hace unos dias hable de la integración con Kenia, ahora Diego nos habla sobre Bugzilla, un interesente blog que no debes dejar de visitar.
Bugzilla desde NetBeans 6.7

Programa en Java y disfruta de un café lojano » Java – Netbeans: SwingWorker & SwingX

Sat, 06 Jun 2009 05:05:12 +0000

A los tiempos escribo.

El tema que les presentaré utiliza varias técnologías: SwingWorker, JXBusyLabel y Java Web Start. El propósito es mostrar cómo funcionan, en parte, cada una de ellas. Paso a explicar mis intenciones.

La aplicación es bastante sencilla, imagínese que al hacer clic en un botón se lanza una tarea que demara alguna cantidad significativa de tiempo, para señalarle al usuario que el programa está trabajando (y no dar la impresión que el programa se colgó) se muestra una animación. Luego que la tarea se ha cumplido la animación deja de trabajar. Para cumplir con lo propuesto se utiliza lo siguiente:

SwingWorker. Una especialización de la clase Thread, que permite realizar tareas ‘por debajo’ de la GUI. La clase SwingWorker crea un hilo que se encarga de hacer la tarea compleja para ello se cuenta con el método doInBackground y cuando la tarea concluye automáticamente se llama al método done. Además la clase SwingWorker trabaja con genéricos de tal forma que permite que el programador defina los tipos de datos de retorno del método doInBackground, en mi caso usé el tipo boolean.

 protected Boolean doInBackground() throws Exception { int i = 0; while(i
      < 100 && !isCancelled()){ Thread.sleep(100); i ++; } return true; } public void done(){ try { etiqueta.setBusy(!get()); boton.setEnabled(get()); } catch (InterruptedException ex) { Logger.getLogger(Tarea.class.getName()).log(Level.SEVERE, null, ex); } catch (ExecutionException ex) { Logger.getLogger(Tarea.class.getName()).log(Level.SEVERE, null, ex); } }

Dentro del método done se puede ver que se existe una llamada al método get() que lo que hace es obtener el valor que retornó el método doInBackground en nuestro caso obtendría true. SwingWorker es un hilo que permite que el hilo que se encarga de la GUI siga trabajando sin interrumpirlo, de esa manera se dá se evita que la GUI se congele. Se creó un clase denominada Tarea que hereda de SwingWorker y posee propiedades del tipo JXBusyLabel y JButton que serán referencias a los elementos que se encuentran en el JFrame.

SwingWorker se encuentra definido desde la versión 1.6 así que es necesario contar con esa versión del JDK.

SwingX es un conjunto de componentes que extienden a los existentes en Swing, entre esos componentes existen uno denominado JXBusyLabel que es un componente que muestra un grupo de líneas colocadas formando una circunferencia (existen otras formas de presentación), cada línea cambia de color dándole así una animación y el la idea de que se está trabajando y que espere hasta que se concluya con la tarea. Veamos el código

 BusyPainter painter = new BusyPainter( new RoundRectangle2D.Float(0, 0, 15.000001f, 5.0f, 10.0f, 10.0f), new Ellipse2D.Float(7.5f, 7.5f, 35.0f, 35.0f)); painter.setTrailLength(4); painter.setPoints(8); painter.setFrame(-1); jxblTrabajando.setPreferredSize(new Dimension(50, 50)); jxblTrabajando.setIcon(new EmptyIcon(50,
      50)); jxblTrabajando.setBusyPainter(painter);

Aún estoy estudiando el código así que no puedo decir mucho, pero podemos ver que no es complicado. El objeto de la clase JXBusyLabel se denomina jxblTrabajando y utiliza la clase BusyPrinter para poder trabajar. Es importante decir que para iniciar la animación se debe llamar al método setBusy(true); en el programa que analizamos se ejecuta dicho método cuándo se hace clic en el botón Iniciar.

Las clases de SwingX son muchas y además existen otros proyectos como JXLayer, Timingframework que permiten hacer muchas otras cosas.

Finalmente Java Web Start es una tecnología Java que permite deployar (descargar e instalar) las aplicaciones desde una página Web superando algunos de los incovenientes que se presentan cuándo se instalan aplicaciones cliente – servidor, como por ejemplo la actualización ya que las aplicaciones JWS primero revisan si la versión de la aplicación instalada en el computador es la misma que la que se encuentra en el servidor, sino es así se descargará la última versión del servidor. Para realizar ésto se utilizó las facilidades que posee NetBeans. Para ello se hizo clic derecho sobre el proyecto, propiedades y luego se busca la opción Web Start se habilita esa opción y listo. Cuando se hace un Clean&Build se generan un archivo jnlp y página html que contienen un link al archivo jnlp. Antes de poder ejecutar las aplicaciones de ésta manera es necesario verificar que tú servidor Web maneje apropiadamente vía tipo MIME los archivo jnlp, verificando si existe la línea: application/x-java-jnlp-file JNLP . Mayores detalles puedes encontrarlos en Deploying Java Web Start Applications

Para ejecutar la aplicación vía Web Start clic aquí

En la aplicación se agregó un check box y un radio button con la final de mostrar cómo la tarea se ejecuta de manera independiente de la GUI. SwingLabs posee muchos componentes muy interesantes y útiles pueden ver los demás aquí y en algún momento la aplicación debería ser así

Para descargar el código haga clic aquí

Saludos.

Avbravo: NetBeans 6.7RC2 disponible

Fri, 05 Jun 2009 20:11:05 +0000

Hace unos días fue liberado el RC1 de NetBeans 6.7, ahora le toca la oportunidad al RC2 de NetBeans 6.7, que son las versiones previas antes del lanzamiento oficial de NetBeans 6.7.
Descargarlo desde aqui

Avbravo: Integración JIRA en NetBeans 6.7RC1

Tue, 02 Jun 2009 17:26:46 +0000

David Salter nos muestra en su blog el uso de NB6.7RC1 con JIRA
http://davidsalter.co.uk/blog/?p=348

Pasos:
1. Instalar los plugins desde el menú
Herramientas Complementos

Al terminar de instalar reiniciamos el IDE

Ahora vamos a prestaciones, seleccionamos Issue Tracker,
damos click derecho y seleccionamos Create Issue Tracker...

Indicamos los datos que se solicitan

Tenemos el issue agregado

Damos click derecho y se muestra el menu

Tenemos una muestra

Integración de Kenai desde NetBeans

Avbravo: NetBeans 6.7RC1 en Español

Tue, 02 Jun 2009 14:41:24 +0000

Ayer comentaba sobre algunas características de NetBeans 6.7 RC1, creo que es importante mencionar que este ha sido liberado en 16 idiomas,

http://download.netbeans.org/netbeans/6.7/rc/

Seleccionamos el idioma que deseamos descargarlo.

Luego nos envía a la pagina de descarga;

Aquí tenemos una muestra del IDE en español.

Es importante recordar que estas traducciones aun no han concluido y faltan varios módulos por traducir y revisar, si encuentran errores pueden comunicarlo.
Tambien para felicitar a los miembros del equipo de traducción de NetBeans que colaboran grandemente para que este IDE este disponible en español.

saludos a todos

Avbravo: Tutorial Creando un Proyecto en Kenai en NB6.7

Mon, 01 Jun 2009 20:04:08 +0000

En el sitio de documentos de NetBeans se ha creado un tutorial que muestra como utilizar Kenia desde NetBeans.

http://www.netbeans.org/kb/docs/ide/kenai-create-project.html?intcmp=925655

Tambien se publico el otro tutorial
Creating a Maven Swing Application Using Hibernate - NetBeans IDE 6.7 Tutorial

Avbravo: NetBeans 6.7RC1 disponible

Mon, 01 Jun 2009 15:16:53 +0000

Ya esta disponible el RC1 de NetBeans 6.7, lo puedes descargar aqui.
Entre algunas características de esta nueva versión:
Integración con Kenai
Integración Bugzilla
Maven

Mas detalles aqui

diesil java: JavaScript en NetBeans 6.1

Thu, 28 May 2009 19:43:57 +0000

Esta entrada fue movida a

http://apuntesdejava.blogspot.com/2008/04/javascript-en-netbeans-61.html

Le Funes » NetBeans: Agregando en NetBeans la Javadoc de librerias opcionales del JDK

Wed, 27 May 2009 11:16:08 +0000

Cuando agregamos librerías opcionales del JDK al mismo, por ejemplo Comm API o JAI, notaremos que sus clases se encontrarán disponibles automáticamente para utilizar dentro del IDE, pero no conseguiremos poder ver su Javadoc. Para poder indicarle a NB donde se encuentra la Javadoc a cargar tenemos que ir al menú ...

Avbravo: Traducción de NetBeans 6.7 en Español

Tue, 19 May 2009 21:04:14 +0000

El equipo de traducción de NetBeans en español se encuentra trabajando en la versión 6.7, por lo cual estas invitado a colaborar en el mismo.
En nuestro Wiki puedes encontrar los pasos para unirte al grupo y colaborar con la traducción.

diesil java: Mudado...!!

Wed, 06 May 2009 18:52:36 +0000

Si eras una de las personas que visitaba este humilde blog, pues te informo que todo lo he cambiado a otra dirección:

http://apuntesdejava.blogspot.com

Ahí están todos los posts... menos los comentarios.

Por ahora no he activado el foro ya que... vamos... no me da tiempo de responder las preguntas.

Avbravo: ubuntu 9.04 parecido a windows

Thu, 30 Apr 2009 20:45:37 +0000

Instale Ubuntu 9.04 en varias pc con ext4 y se me parece mas ha Windows XP, se congela a cada rato, varios programas no estan en los repositorios, entre ellos MySQL, PostGreSQL.
sudo apt-get install mysql-server
Leyendo lista de paquetes... Hecho
Creando árbol de dependencias
Leyendo la información de estado... Hecho
Tal vez quiera ejecutar `apt-get -f install' para corregirlo:
Los siguientes paquetes tienen dependencias incumplidas:
mysql-server: Depende: mysql-server-5.0 pero no va a instalarse
shutter: Depende: libxml-simple-perl pero no va a instalarse
Depende: libwww-mechanize-perl pero no va a instalarse
Depende: libgnome2-gconf-perl pero no va a instalarse
Depende: libgnome2-wnck-perl pero no va a instalarse
Depende: imagemagick
Depende: perlmagick
Depende: libgtk2-imageview-perl pero no va a instalarse
Depende: libx11-protocol-perl pero no va a instalarse
Depende: libgtk2-trayicon-perl pero no va a instalarse
Depende: libgoo-canvas-perl pero no es instalable
Depende: gnome-web-photo pero no va a instalarse
E: Dependencias incumplidas. Intente 'apt-get -f install' sin paquetes (o especifique una solución).

Avbravo: NetBeans 6.7 Beta

Tue, 28 Apr 2009 16:50:02 +0000

Ya esta disponible la versión 6.7 Beta de NetBeans
puedes obtener información aquí.
http://www.netbeans.org/community/releases/67/index.html

Avbravo: Alexandre Oliva en FLISOL Panama 2009

Thu, 16 Apr 2009 18:52:20 +0000

La fraternidad de Software Libre de Panamá, esta organizando junto con otras comunidades en Panamá el "Festival Latinoamericano de Software Libre " FLISOL 2009.
Se contaran con talleres, charlas, installfest, para promover el uso del software libre.
En esta ocasión se contara con la presencia de Alexandre Oliva
Puedes visitar su pagina principal aqui

Este evento se realizara simultáneamente en varias ciudades de Panamá.
PanamaJUG esta organizando FLISOL 2009 en la península de Azuero.

Avbravo: Cambios importantes en NetBeans

Thu, 16 Apr 2009 13:24:06 +0000

Como comenta James Branam algunos cambios que serán aplicados a NetBeans
entre ellos UML, Visual Web, y SOA seran movidos al Update Center.
Puedes visitar el enlace en el blog de James
http://blogs.sun.com/branajam/entry/uml_visual_web_and_soa

Avbravo: Java Cup 2009

Mon, 13 Apr 2009 22:47:13 +0000

Amigos, para este año 2009, ya esta abierta Java Cup 2009.
Información en JavaHispano

La revista Sólo Programadores, Sun Microsystems Ibérica y la organización sin ánimo de lucro javaHispano hemos organizado la tercera versión del torneo virtual de fútbol JavaCup donde cada equipo es una clase Java que implementa una interfaz predefinida. El concurso cuenta con el patrocinio de las empresas Kotasoft, en calidad de patrocinador de oro, y Salenda como patrocinadores de plata. La participación está abierta a cualquier hispanohablante, sin importar su nacionalidad.

Desarrollar un equipo de fútbol es simple ya que el software en el cual se basa el concurso se encarga de dibujar en la pantalla y gestionar los movimientos de la pelota y de los dos equipos. Para crear un equipo lo único que hay que indicar es qué movimientos quieres que realice tu equipo en cada situación, lo cual es sencillo gracias a la API que expone a los equipos el software.

Como recordaran en la versión 2008 del torneo no se modifico el framework original, en cambio, para esta nueva versión se ha reescrito por completo el framework, añadiendo características nuevas, tanto en la gráfica, como en el audio, y en la lógica del juego. Pese a esto, se desea mantener la estructura básica original de las JavaCup anteriores.

Premios

El ganador del concurso recibirá 1000 €, el segundo clasificado recibirá 500 €, el tercero 250 € y el cuarto 125 €. Además, todos ellos recibirán una suscripción anual a la revista Sólo Programadores. Los ganadores del concurso se anunciarán en el evento tecnológico OpenJavaDay, que se celebrará el 18 y 19 de junio en España, Madrid.

Recuerden visitar el enlace en JavaHispano con toda la documentación al respecto.

Avbravo: Flisol Panama 2009

Mon, 13 Apr 2009 14:35:15 +0000

PanamaJUG se ha unido a otras comunidades de software libre en el Festival Latinoamericano de Instalación de Software Libre, con el lema "Tu crees que eres libre si tu software no lo es"
que se realizara en varias ciudades de la República de Panamá, a la cual eres invitado a participar, este evento se realizara el día 25 de Abril

Avbravo: Sistema de Actualizacion usando FTP solamente

Thu, 09 Apr 2009 01:40:44 +0000

Hay muchas formas de actualizar nuestro proyecto Desktop, Java Web Start es una gran alternativa. Miremos otra situación, tal vez nuestros clientes poseen una conexión de Internet limita a un ancho de banda muy pequeño o con cualquier otra limitación como inconsistencia en el mismo.
Si la situación es esta , desarrollar una aplicación Web no es factible, y queremos implementar una alternativa a Java Web Start, si esta es nuestra decisión, podemos desarrollar una aplicación Desktop, donde dividimos nuestro proyecto en pequeños módulos o sub-proyectos, que seran integrados en el proyecto principal, y a cada modulo crearemos una clase que contendrá la versión del módulo, con un formato sencillo: año.mes.dia.horaminutos, luego crearemos una clase que generara un archivo xml con la información del numero de versión de todos los módulos y este archivo junto con los módulos que sufran cambios serán subidos por el desarrollador al servidor ftp. En el cliente al iniciar el sistema simplemente descarga el archivo .xml que contiene las versiones de los modulos en el servidor ftp, y los compara con las versiones de los módulos local mente, y si hay cambios solo se descargaran aquellos que han cambiado.

Desarrollador: Generar archivo xml de versiones

Generando la versión de cada módulo en el archivo xml.

El desarrollador sube el archivo xml

y los modulos que se han actualizado (archivos .jar)

Cuando el usuario entra al sistema

Mensaje de Actualización en el menu

Actualizamos los modulos, el sistema nos indica las diversas versiones, locales y web de los modulos que han sido actualizados.

Mensaje de terminación de actualización de módulos(descarga de los .jar actualizados).

Esta es solo otra forma de hacerlo, existen muchas más, era un simple ejemplo que podemos implementar en nuestros proyectos.

Avbravo: NetBeans 6.7 M3 para descarga

Thu, 02 Apr 2009 13:50:42 +0000

Ya esta disponible el M3 de NetBeans 6.7, puedes descargarlo desde el siguiente enlace.
http://bits.netbeans.org/download/6.7/m3/

Avbravo: Comparativa de Tomcat y GlassFish

Fri, 27 Mar 2009 20:19:03 +0000

Sun Inner Circle publica un innforme comparativo entre GlassFish vs Tomcat.
¿GlassFish o Tomcat? ¿Cuál le conviene?

http://www.sun.com/emrkt/innercircle/newsletter/0209/feature-itm.html

http://mx.sun.com/emrkt/innercircle/newsletter/0209/feature-itm.html?cid=e7959f

Héctor: RECASPITAS

Tue, 24 Mar 2009 05:00:21 +0000

Que memoria la mia :doh: sabia que olvidaba algo, no cabe duda que la edad hace estagos :lol: :lol:

El mes pasado (febrero) el blog cumplio 3 años!! :no: como pude olvidarlo :no:

:hat: :drunk: un poco tarde pero siempre es motivo de festejar :drunk: :hat:

Aun no se que hace que lo mantenga o no he encontrado una razon para dejarlo.

Avbravo: CRUD Application on the NetBeans Platform (Part 1)

Sat, 21 Mar 2009 19:06:50 +0000

Geertjan Wielenga , presenta este vídeo acerca de CRUD Application on the NetBeans Platform.
Es una serie de dos vídeos, en esta primera parte integra una base de datos MySQL en NetBeans Platform utilizando EclipseLink.

Sin duda no debes perder la oportunidad de verlo.

Actualización:

Geertjan, completo el video de la creación de la aplicación CRUD on the NetBeans Platform
http://blogs.sun.com/geertjan/entry/completed_crud_application_on_the

Héctor: unable to connect

Tue, 10 Mar 2009 19:27:50 +0000

Me encuentro haciendo un sitio web como proyecto de una materia en la uni, usando PHP, Apache, MySQL y claro GNU/Linux :) .

El problema es que hago uso de los google maps, para desarrollar uso netbeans y su modulo para php ya que permite incluir el servicio de una manera muy facil:

Lo malo es que hasta el domingo se mostraba el mapa sin problemas, pero hoy solo muestra:

fsockopen() [function.fsockopen]: unable to connect to maps.google.com:80 (php_network_getaddresses: getaddrinfo failed: Temporary failure in name resolution)

¿Que opinan?

Programa en Java y disfruta de un café lojano » Java – Netbeans: JavaFX e interacción con base de datos

Sat, 07 Mar 2009 05:28:36 +0000

Buscando ejemplos de aplicaciones JavaFx, me he encontrado con el siguinte blog JFXStudio, el mismo que muestra una gran cantidad de ejemplos sobre JavaFx, acompañados de su código fuente.

Uno de los ejemplos que más me ha llamado la atención es uno que trabaja con base de datos. El ejemplo es una evolución de otro, que se detalla aquí. En la evolución se puede ver una interfaz más desarrollada y enriquecida que la original.

Lo interesante del post original es que detalla el trabajo con base de datos, una de las tareas que son necesarias en cualquier tipo de aplicación. En éste ejemplo podemos ver el potencial para la creación de GUI que posee JavaFX y cómo interactuar con bases de datos. Pueden encontrar el código fuente del proyecto de NetBeans.

Un imagen de ejemplo: tomada desde JavaFXStudio

“]

GUI JavaFX y base de datos [Tomada desde: http://jfxstudio.wordpress.com/2009/03/03/the-graphic-database-front-end/

Espero que les ayude.

Bits y Bytes » NetBeans: Métricas de calidad con NetBeans y Hudson

Thu, 05 Mar 2009 18:21:41 +0000

Este artículo como PDF.

Introducción

En un post anterior expliqué cómo montar un entorno de integración continua básico, que luego completamos para que también se convirtiera en un verdadero entorno TDD con tests y métricas de cobertura. El siguiente paso para tener un entorno totalmente ágil consiste en añadir métricas de calidad de código para favorecer la mejora continua del trabajo hecho por todo el equipo y para que los gestores puedan tener una perspectiva algo más “objetiva” del nivel de calidad. Continuaré en este tutorial sobre el mismo ejemplo, así que en numerosos puntos haré referencias a los artículos previos para no tener que repetirme más de lo necesario.

Nótese que he puesto la palabra objetiva entre comillas. En este artículo vamos a ver una serie de herramientas que detectarán malas prácticas, bugs potenciales o puntos mejorables y generarán informes al respecto. El desarrollo de software es algo muy complejo y la medida de su calidad real no es automatizable (si así fuera, también lo sería su desarrollo y aún no hemos llegado a ese punto), ni hay un convenio universal de en qué consiste, con lo cual hay que saber leer e interpretar el resultado que producen estas herramientas. Si están avisando de que nuestro código tiene problemas, muy probablemente tengan razón y deberemos poner medidas correctoras. Lo contrario, sin embargo, no implica que nuestro código sea de alta calidad, sino que no se han encontrado aquellas cosas que se sabe que producen problemas. No se podrá automatizar, por ejemplo, cosas como la detección de uso inadecuado de patrones de diseño o la escalabilidad de la plataforma, que podríamos estar de acuerdo que son medidas de calidad. Simplificando mucho: se puede detectar que el código de un proyecto tiene poca calidad de manera automática, pero no se puede decir que para aquellos para los que no se ha detectado, el código sea de alta calidad.

Hechas estas matizaciones, en este artículo vamos a explicar cómo integrar las siguientes herramientas en NetBeans y Hudson usando Ant:

Checkstyle : genera informes sobre el grado de seguimiento del código a los estándares de codificación establecidos.
Simian : detector de copia de bloques de código.
PMD : analizador de código estático en busca de posibles bugs y malas prácticas.
FindBugs : similar al anterior.

El procedimiento de instalación de las herramientas va a ser análogo para cada una de ellas:

Instalación del plugin correspondiente en el NetBeans (si lo hubiere) y configuración del mismo.
Instalación de las bibliotecas de la herramienta en la máquina de desarrollo.
Modificación del script del Ant para poder lanzar el análisis sin la ayuda del IDE.
Instalación del plugin correspondiente en el Hudson.
Modificación del job para incluir la generación y publicación de informes correspondientes.

Checkstyle

Cuando hablo de estilo de codificación (o convenciones de código) me refiero a cosas como el nivel de indentación, utilizar espacios o tabuladores, añadir comentarios, cómo organizar las llaves de los bloques de código, el tamaño máximo de la línea, etcétera.

Parece un hecho ampliamente aceptado que la uniformidad de estilo a la hora de codificar facilita el grado de cohesión del equipo de desarrollo, la mantenibilidad de la base de código y en definitiva la productividad. Si todo el equipo trabaja con un mismo estilo, puede entender la estructura del programa más fácilmente de un vistazo.

En el mundo Java, Sun proporcionó unas guías de estilo que han sido ampliamente adoptadas por la comunidad. En este documento las podéis encontrar junto con los motivos que hay detrás de cada convención.

Checkstyle es una herramienta que genera informes del nivel de seguimiento de estas convenciones. Seguir el estilo al pie de la letra puede resultar algo duro en ocasiones, así que también es posible rebajar el nivel de exigencia decidiendo para qué convenciones se quiere generar una alarma y cuáles se puede ignorar o incluso para definir nuestras propias convenciones.

Checkstyle lo tenemos disponible en las tres vertientes: plugin para el NetBeans, como task del Ant y como plugin del Hudson.

Plugin para NetBeans del Checkstyle

El plugin no forma parte de los repositorios estándar, así que el primer paso para instalarlo será añadir el repositorio correspondiente. Para ello iremos a: Tools -> Plugins -> Settings -> Add y añadiremos la siguiente url : http://www.sickboy.cz/checkstyle/autoupdate/autoupdate.xml tal y como se muestra en las siguientes imágenes.

A continuación hacemos click en la pestaña de Available Plugins y seleccionamos Checkstyle Beans Library y Checkstyle Beans Plugin y los instalamos (seguimos los pasos indicados por el asistente y cuando nos pregunte si queremos instalar plugins no firmados le decimos que sí) . Ahora sólo resta reiniciar el NetBeans para que cargue el plugin.

Ahora cada vez que alguna línea de código no conforme con respecto a las convenciones de Sun, aparecerá una etiqueta a modo de aviso. Poniendo el ratón encima de la etiqueta, mostrará cuál es la convención que no se está siguiendo.

Como decía, se pueden utilizar plantillas con convenciones personalizadas. Para ello deberemos editar la configuración por defecto que se encuentra en: Tools -> Options -> Miscellaneous -> Checkstyle.

Incluir Checkstyle en el script de Ant del NetBeans

Como ya he explicado en otros artículos, NetBeans realiza todas sus tareas mediante scripts Ant que autogenera y el build.xml que hay en la raíz del proyecto es extensible para que los desarrolladores podamos introducir nuestros propios targets .

Lo primero que tenemos que hacer es descargarnos la distribución del Checkstyle (en el momento de escribir este artículo la versión 5 sigue siendo beta , así que yo me decanto por la versión 4.4) que, entre otras cosas, aporta los tasks necesarios para invocarlo desde Ant. A continuación habremos de descomprimir el paquete en algún lugar de la máquina de desarrollo. Yo, siguiendo mi propio estándar, lo situaré en el directorio /srv y luego lo enlazaré con un link simbólico para no tener que hardcodear la ruta hacia una versión concreta en ningún fichero de configuración o script que haga uso del mismo. También crearé un enlace simbólico al jar que contiene la implementación del task por el mismo motivo.

root@hargon:/srv# tar -zxf checkstyle-4.4.tar.gz root@hargon:/srv# ln -s checkstyle-4.4 checkstyle root@hargon:/srv# ls -alh checkstyle lrwxrwxrwx 1 root root 14
      2009-02-25 16:24 checkstyle -> checkstyle-4.4 root@hargon:/srv# rm checkstyle-4.4.tar.gz root@hargon:/srv# cd checkstyle root@hargon:/srv/checkstyle# ln -s checkstyle-all-4.4.jar checkstyle-all .jar

El siguiente paso consiste en modificar el build.xml . Lo primero que vamos a necesitar es importar el task tal y como sigue:

<taskdef  resource="checkstyletask.properties"  classpath="${checkstyle.dir}/checkstyle-all.jar"/>

Puesto que el valor de checktyle.dir puede ser diferente en la máquina de diferentes desarrolladores o en la máquina que contiene en el servidor de integración, esta propiedad la definimos en el fichero de propiedades privadas del proyecto (que recordemos no forma parte del repositorio de código): nbproject/private/private.properties.

checkstyle.dir=/srv/checkstyle

Como yo estoy partiendo del mismo ejemplo del artículo previo donde explicaba cómo integrar Cobertura, yo ya tengo definido un import en el build.xml del fichero de propiedades privadas, si no lo tuvierais acordaros de añadirlo.

<property file="nbproject/private/private.properties"/>

A continuación definimos el target que construirá los informes en el build.xml :

<target name="checkstyle-report">  <property file="nbproject/project.properties"/>  <mkdir dir="${checkstyle.report.dir}"/>  <checkstyle
      failOnViolation="false"   config="${checkstyle.dir}/sun_checks.xml">   <fileset dir="${src.dir}" includes="**/*.java"/>   <formatter type="xml"
         toFile="${checkstyle.report.dir}/checks.xml"/>   <formatter type="plain"    toFile="${checkstyle.report.dir}/checks.txt"/>  </checkstyle> </target>

El target es bastante fácil de entender. En primer lugar construimos el directorio donde se generarán los diferentes informes. A continuación lanzamos el task del Checkstyle indicándole que siga procesando el build.xml aunque se encuentren fallos de formato ( failOnViolation=”false” ) y que utilice las convenciones definidas en el fichero sun_checks.xml que forma parte de la distribución estándar de Checkstyle. Este fichero es donde se describen, en un formato que escapa al ámbito de este artículo, cuáles son las convenciones que caso de no seguirse generan un aviso. Obviamente podemos editar o sustituir este fichero por otro adaptado a nuestras necesidades, pero si dejamos éste, forzamos las convenciones de Sun que, como ya había indicado previamente, se describen en este documento .

Finalmente generamos los informes en dos formatos: en texto plano y en XML. El primero es más sencillo de leer por humanos pero el segundo es el adecuado para integrarlo con Hudson.

En este target presuponemos inicializadas las propiedades checkstyle.dir , src.dir y checstyle.report.dir . La primera ya la hemos configurado en el punto anterior, la segunda forma parte de las propiedades creadas por NetBeans y la última la tenemos que definir. Las añadiremos como propiedades del proyecto en el nbproject/project.properties :

reports.dir=${build.dir}/reports checkstyle.report.dir=${reports.dir}/checkstyle-report

Integrando Checkstyle con Hudson

Para generar los informes en Hudson nos aprovecharemos del target que acabamos de definir en el build.xml del NetBeans, por tanto el proceso va a ser sencillo:

añadir el plugin del Checkstyle al Hudson,
instalar las bibliotecas del Checkstyle en la máquina donde reside el Hudson,
añadir las propiedades privadas a mano (recordad que este fichero no forma parte del Subversion),
añadir el nuevo target en la construcción del proyecto,
configurar el job para que utilice el target .

El proceso para instalar el plugin, ya lo hemos visto en el post donde explicaba cómo añadir el plugin de Cobertura . Básicamente, seleccionarlo de la lista de plugins disponibles, instalarlo con el asistente y reiniciar el Hudson.

Utilizaré el mismo procedimiento y ruta para instalar la distribución del Checkstyle en el servidor donde se ejecuta el Hudson, así que repetiré exactamente los mismos pasos que hice en la máquina de desarrollo.

A continuación tenemos que modificar las propiedades privadas para añadir la ruta al Checkstyle. Nos situaremos en el directorio del job y editaremos (o crearemos) el fichero nbproject/private/private.properties para añadir la línea:

checkstyle.dir=/srv/checkstyle

Finalmente añadimos checkstyle-report a la lista de tagets a construir y configuramos el job para que lea los informes generados en xml y los publique. Adicionalmente podemos configurar opciones avanzadas como los límites a partir de los cuales el build debe considerarse inestable o roto.

Ahora ya sólo resta ver los informes que genera el Hudson:

Simian

Alguna vez oí, aunque no recuerdo la fuente, que en informática la duplicación es el diablo y yo no puedo estar más de acuerdo. En ciertas ocasiones requerimientos no funcionales, como por ejemplo eficiencia, puede requerir duplicar información (denormalización de tablas en bases de datos, materialización de cálculos de agregación de información, etc), pero ello debe ser consecuencia de una decisión de diseño meditada y no de la dejadez. La replicación de código, en general, es menos justificable e introduce un gran coste en mantenibilidad y calidad: modificaciones en cualquiera de las copias debería llevar aparejadas actualizaciones en el resto, lo cual se hace muy tedioso y complicado de implementar.

Por todo lo anterior, si tenemos repetido un bloque de código de un tamaño razonable, probablemente ello está descubriendo un mal diseño y ese código debería encapsularse de alguna manera para que exista en un único punto.

Simian es la herramienta que nos va a permitir encontrar replicación de bloques de código (o de texto en general) en una gran cantidad de lenguajes de programación y formatos de texto. Hasta donde yo sé, no existe como plugin para NetBeans (aunque sí para Eclipse e IntelliJ). Sí que existe el task para Ant y como plugin para el Hudson y por tanto veremos estas configuraciones.

Como el procedimiento para incluir nuevas herramientas de análisis y métricas va a ser siempre muy similar a lo que he explicado en el caso del Checkstyle, no explicaré el proceso de una manera tan detallada (entre otras cosas porque no aporta nada y sólo hace crecer el documento).

Incluir Simian en el script de Ant del NetBeans

Lo primero es obtener y configurar la herramienta en el entorno de desarrollo, para ello lo descargamos , lo descomprimimos en /srv / (id con cuidado porque el paquete no contiene un directorio raíz) y creamos el enlace simbólico correspondiente.

root@hargon:/srv# mkdir
      simian-2.2.24 root@hargon:/srv# cd simian-2.2.24 root@hargon:/srv/simian-2.2.24# mv ../simian-2.2.24.tar.gz . root@hargon:/srv/simian-2.2.24# tar -zxf simian-2.2.24.tar.gz root@hargon:/srv/simian-2.2.24# rm simian-2.2.24.tar.gz root@hargon:/srv/simian# cd bin/ root@hargon:/srv/simian/bin# ln -s
      simian-2.2.24.jar simian.jar root@hargon:/srv/simian-2.2.24# cd ../.. root@hargon:/srv# ln -s simian-2.2.24 simian

A continuación configuramos el build.xml de manera análoga al Checkstyle:

<taskdef  resource="simiantask.properties"  classpath="${simian.dir}/bin/simian.jar"/> <target name="simian-report">  <property file="nbproject/project.properties"/>
       <mkdir dir="${simian.report.dir}" />  <simian>   <fileset dir="${src.dir}" includes="**/*.java"/>  
      <formatter type="xml"    toFile="${simian.report.dir}/simian.xml"/>   <formatter type="plain"    toFile="${simian.report.dir}/simian.txt"/>  </simian> </target>

Las propiedades las definiremos allí donde toca: el simian.dir (con valor /srv/simian ) en el nbproject/private/private.properties y el simian.report.dir (con valor ${reports.dir}/simian-report ) en el nbproject/project.properties .

El task de Simian es muy sencillo. En su configuración simple tal y como tenemos, tan sólo hace falta especificar el directorio que contiene el código a analizar y el formato de los informes (en XML para integrarse con el Hudson y en texto plano para que sea más legible por humanos).

Integrando Simian con Hudson

Como en el caso del Checkstyle, replicamos la instalación de Simian en la máquina donde se encuentra el Hudson y definimos la propiedad simian.dir en el nbproject/private/private.properties .

El siguiente paso debería consistir en instalar el plugin del Simian para el Hudson, pero cuando lo buscamos en la lista de plugins disponibles nos damos cuenta que no aparece. Afortunadamente existe un plugin llamado Violations que integra diferentes herramientas de análisis estático de código (de hecho podríamos utilizar este mismo plugin para otras de las tratadas en este artículo) y que tiene soporte para Simian. Lo instalamos de la manera habitual, reiniciamos el Hudson para que lo cargue y el siguiente paso consiste en configurar el job . Como siempre, añadiremos el simian-report a la lista de targets a construir por el Ant y a continuación configuramos el plugin tal y como se muestra en la ilustración (también podemos definir los límites a partir de los cuales se rompe el build ).

Tras construir el job podremos ver los informes de replicación de código de manera integrada en el Hudson.

PMD

Tanto PMD como FindBugs, son herramientas de análisis estático de código (analizan el código y no el programa en ejecución) en busca de estructuras potencialmente peligrosas tales como:

posibles bugs,
código “muerto” (variables no accedidas, bloques de ejecución inalcanzables, etc.),
código subóptimo,
bloques con una estructura poco legible o más complicada de lo necesario.

Estas herramientas son especialmente útiles integradas en el IDE porque de esta manera el programador puede ir viendo mientras escribe el código las posibles alertas. Obviamente también tienen tasks de Ant lo que permite integrarlas fácilmente en Hudson para obtener los informes correspondientes.

Plugin para NetBeans del PMD

En este caso el plugin del PMD no está accesible mediante un repositorio, por lo que para instalarlo procederemos a la descarga del mismo y a su instalación local.

Una vez tenemos el fichero, deberemos descomprimirlo y nos quedamos con el plugin empaquetado en el fichero pmd.nbm que instalaremos a través la pestaña Downloaded del gestor de plugins: primero lo añadimos a la lista mediante el botón Add Plugins y después le damos a Install .

Aceptamos la licencia, asumimos el riesgo de instalar un plugin “no firmado” y rebotamos el IDE para que se reflejen los cambios.

En este momento el plugin debería estar listo para ser utilizado. Mientras trabajamos PMD monitorizará el código que escribimos y nos pondrá una marca en el editor cuando algo no le guste. Si ponemos el puntero encima de la marca, se nos mostrará un mensaje informativo del problema en forma de tooltip .

Si queremos obtener un informe de todos los posibles problemas en una carpeta de código, paquete o clase, sobre la ventana Projects hacemos click derecho en el elemento correspondiente -> Tools -> Run PMD.

Ello abrirá una nueva pestaña de informe con todas los avisos disponibles en forma de tabla (permitiendo ordenación por las diferentes columnas). Haciendo doble click sobre cualquiera de las advertencias, el editor se desplazará a la línea de código correspondiente.

PMD puede ser muy estricto y es posible que nos interese personalizar el tipo de alertas generadas y, quizá, desactivar algunas. Hay que encontrar un compromiso entre lo razonable y la calidad. Por ejemplo, algunas de las estructuras autogeneradas por el IDE (como el equals mostrado en el ejemplo unas líneas más arriba) producen advertencias que podríamos ignorar con tranquilidad ya que NetBeans sabe lo que hace . Para modificar la configuración del plugin y el tipo de reglas que aplicar, nos vamos al menú de opciones: Tools -> Options -> Miscellaneous.

Las reglas se gestionan mediante rulesets temáticos. Es decir un ruleset puede contener todas aquellas reglas ( rules) que tengan que ver, por ejemplo, con código muerto. Mediante el menú de rulesets podemos incluir o no las incluidas con PMD y añadir otras propias generadas por nosotros o por terceros. En el menú Manage rules se nos permite la activación o desactivación de reglas individuales.

Incluir PMD en el script del Ant de NetBeans

De manera análoga a las herramientas anteriores, descargamos e instalamos la herramienta en /srv .

root@hargon:/srv# unzip -q pmd-bin-4.2.5.zip root@hargon:/srv# ln -s pmd-4.2.5/ pmd root@hargon:/srv# rm pmd-bin-4.2.5.zip root@hargon:/srv# cd pmd/lib/ root@hargon:/srv/pmd/lib# ln -s pmd-4.2.5.jar pmd.jar

A continuación modificaros el build.xml de manera adecuada.

<taskdef name="pmd"  classname="net.sourceforge.pmd.ant.PMDTask"  classpath="${pmd.dir}/lib/pmd.jar"/> <target name="pmd-report">  <property   file="nbproject/project.properties"/>
        <mkdir dir="${pmd.report.dir}" />  <pmd shortFilenames="true">   <ruleset>unusedcode,basic,design,controversial</ruleset>   <formatter type="xml"    toFile="${pmd.report.dir}/pmd.xml"    linkPrefix="http://pmd.sourceforge.net/xref/" />   <formatter type="html"    toFile="${pmd.report.dir}/pmd.html"    linkPrefix="http://pmd.sourceforge.net/xref/" />   <fileset dir="${src.dir}">    <include name="**/*.java"/>   </fileset>  </pmd> </target>

Las propiedades las añadimos al fichero correspondiente: el pmd.dir (con valor /srv/pmd ) en el nbproject/private/private.properties y el pmd.report.dir (con valor ${reports.dir}/pmd-report ) en el nbproject/project.properties .

El task del PMD es sencillo de utilizar. Primeramente indicamos qué rulesets de los estándar queremos analizar (podríamos también especificar rulesets personalizados) y a continuación indicamos en qué formatos queremos generar los informes. Como es habitual, tendremos los informes en XML que se integran bien con Hudson y en formato HTML para ser leídos por humanos.

Integrando PMD con Hudson

Al igual que las dos herramientas anteriores, instalamos PMD en el servidor de integración y definimos la propiedad pmd.dir en el nbproject/private/private.properties .

A continuación instalamos el plugin del PMD del Hudson de la manera habitual (no olvidéis rebotar lo) y ya podemos proceder a la configuración del job tal y como se muestra en la siguiente captura. Obviamente podemos establecer los límites que por defecto, como casi siempre, están desactivados.

Y estos serían los informes generados.

FindBugs

Sin entrar en demasiados detalles, FindBugs es una herramienta similar a la anterior. En el momento de escribir este tutorial todavía no existe una versión compatible del plugin para NetBeans 6.5, pero los ingenieros de FindBugs están trabajando en ello y me imagino que estará disponible en breve (sí que existen versiones funcionales para otros IDEs).

Incluir FindBugs en el plugin de Ant de NetBeans

Procedemos a descargar el paquete para instalarlo de la manera habitual.

root@hargon:/srv# tar -zxf findbugs-1.3.7.tar.gz root@hargon:/srv# ln -s findbugs-1.3.7 findbugs root@hargon:/srv# ls -alh findbugs lrwxrwxrwx 1 root root 14 2009-03-05 15:55 findbugs -> findbugs-1.3.7

A continuación modificamos el build.xml para añadir un target que use el task del NetBeans.

<taskdef name="findbugs"  classname="edu.umd.cs.findbugs.anttask.FindBugsTask"  classpath="${findbugs.dir}/lib/findbugs.jar" /> <target name="findbugs-report" depends="compile">   <property file="nbproject/project.properties"/>
       <mkdir dir="${findbugs.report.dir}"/>  <findbugs home="${findbugs.dir}"   output="xml"   outputFile="${findbugs.report.dir}/findbugs.xml">     <sourcePath path="${src.dir}" />   <class location="${build.classes.dir}" /> 
      </findbugs> </target>

Como en los casos anteriores, añadimos las propiedades a los ficheros correspondientes: el findbugs.dir (con valor /srv/findbugs ) en el nbproject/private/private.properties y el findbugs.report.dir (con valor ${reports.dir}/findbugs-report ) en el nbproject/project.properties .

El task del FindBugs requiere no sólo el código fuente sino también las clases compiladas y por ello el target tiene una dependencia del target estándar de NetBeans compile . Las clases compiladas se referencian mediante una propiedad también estándar de NetBeans: build.classes.dir .

El resto de propiedades son las típicas que hemos ido viendo, el directorio de instalación de la herramienta y el directorio de salida de los informes.

En este caso estamos generando los informes en XML que son los que entiende Hudson, pero también pueden generarse en otros formatos, como en texto plano o en HTML.

Integrando FindBugs con Hudson

Como siempre, replicamos la instalación del FindBugs en la máquina donde está instalado el Hudson y definimos la propiedad findbugs.dir apuntando al directorio correspondiente en el nbproject/private/private.properties .

FindBugs también tiene un plugin nativo para Hudson, así que lo instalamos y reiniciamos. A continuación, de manera totalmente análoga al PMD, configuramos el nuevo target y las opciones de FindBugs.

Finalmente ya podemos ver los informes generados.

Conclusión

En este artículo hemos aprendido que existen herramientas que nos pueden ayudar a generar métricas sobre la calidad de nuestro código. También hemos enfatizado el hecho que obtener un 100% de puntuación no garantiza un software de calidad.

Hemos visto que las herramientas suelen venir en tres “sabores”: como plugin para el IDE que dan un feedback inmediato al programador, como task del Ant que permiten ejecutarlas en modo consola e integrarlas con otros sistemas y como plugin para Hudson que permite publicar los informes correspondientes de una manera agradable para los humanos.

Existen muchas más herramientas de calidad. En próximos artículos tocaré algunas mas.

Tagged: Agile, Ant, calidad, Hudson, Java, NetBeans

Avbravo: NetBeans Community Docs 300

Mon, 02 Mar 2009 14:47:00 +0000

La participación de la comunidad cada vez es más influyente, ya llegamos a los 300 documentos en el NetBeans Community Docs
Todos son invitados a colaborar aportando sus documentos y compartiendo sus conocimientos con los demas miembros de la comunidad.

Avbravo: Integrando Gtalk en una aplicacion Desktop

Fri, 27 Feb 2009 00:59:00 +0000

Luego de varias semanas sin escribir en mi blog, ya que estado super ocupado con unos proyectos, escribo nuevamente para colocar un ejemplo bastante simple de como integrar un chat para Gtalk en nuestras aplicaciones Desktop.

El codigo lo puedes encontrar en el wiki del Community Docs, en este enlace.

Su funcionamiento es muy simple, el cliente tiene una cuenta en Gmail, y simplemente al entrar automaticamente se configura para enviar mensajes a mi cuenta avbravo@gmail.com, de esta manera, establezco comunicación con el cliente sin que el tenga que salir de su aplicacion Desktop.

Bits y Bytes » NetBeans: Cobertura con NetBeans y Hudson

Sat, 07 Feb 2009 19:00:41 +0000

Este artículo como PDF.

Introducción

Una vez tenemos montado un entorno TDD, y si efectivamente estamos trabajando con esta orientación, nuestro proyecto empezará a acumular tests unitarios con JUnit o cualquier otro framework lo que permitirá a nuestro servidor de integración (Hudson) utilizarlos como tests de regresión.

Si estamos siendo estrictos en la aplicación de una metodología TDD, en principio el grado de cobertura del código (el porcentaje de líneas de código que son evaluadas por un test) debería estar cerca del 100% por aquello del “ escribe primero el test y luego el código que lo supera”. Sin embargo bien porque seamos principiantes aplicando la metodología o bien porque escribamos los tests como parte del proceso de calidad en una metodología diferente, puede resultar muy complicado calcular el grado de cobertura mediante técnicas manuales. Incluso en un entorno TDD maduro, la propia complejidad del software puede complicar extraer esta información. Es por ello que se han desarrollado una serie de frameworks y herramientas que permiten automatizar este proceso.

Como decía, no estamos solos ante el peligro y tenemos herramientas diversas y con todo tipo de licencias. Por citar algunas: Clover, EMMA, VectorCAST o Cobertura. Mi elección en este caso será la última por varios motivos: es un producto open source (por los que tengo debilidad, especialmente cuando uno es autónomo), ofrece tasks para usarlo desde Ant y tiene plugins para Hudson. Es una lástima que no tenga un plugin nativo para NetBeans, aunque como el IDE nos permite ejecutar targets de Ant fácilmente, se lo podemos perdonar.

Por cierto, existe un plugin de análisis de cobertura de código para NetBeans. No he jugado mucho con él, pero parece que es un servicio que sólo puede activarse para proyectos de JSE y no está disponible, por ejemplo, para un proyecto web. Si alguien tiene experiencia con el mismo, se agradecerá el feedback.

Gran parte de la información necesaria que he usado para escribir esta entrada la he obtenido de este post .

Configurar Cobertura en el NetBeans

El proceso es sencillo:

descargar el software,
instalarlo,
modificar el build.xml del NetBeans.

Así pues, lo primero que tenemos que hacer es descargarnos el software desde SourceForge. Nosotros vamos a contentarnos con la versión binaria y dejaremos el hacking para otro momento. A continuación procederemos a la instalación que no es más que descomprimirlo en una carpeta de la máquina de desarrollo. Yo tengo la costumbre de instalar estas cosas en el directorio /srv y además suelo crear un enlace simbólico (que será el que referencie desde los proyectos) que no incluya el número de versión para que cada vez que haga una actualización no tenga que recorrer todos los scripts para corregir la referencia.

root@hargon:/srv# tar -zxf cobertura-1.9.1-bin.tar.gz root@hargon:/srv# ln -s cobertura-1.9.1 cobertura root@hargon:/srv# ls -alh total 684K drwxr-xr-x 7 root root 4,0K 2009-02-07 13:42 . drwxr-xr-x 21 root root 4,0K 2009-02-07 11:23 .. lrwxrwxrwx 1 root root 15 2009-02-07 13:42 cobertura -> cobertura-1.9.1 drwxr-xr-x 4 root
      root 4,0K 2009-02-04 21:23 cobertura-1.9.1 -rw-r--r-- 1 root root 649K 2009-02-04 21:40 cobertura-1.9.1-bin.tar.gz root@hargon:/srv# rm cobertura-1.9.1-bin.tar.gz

Como ya he explicado en alguna ocasión, NetBeans usa scripts de Ant para realizar todas sus tareas y están modularizados de manera que podamos introducir nuestros propios targets y personalizaciones. En particular el fichero que podemos “tocar” tranquilamente es el build.xml que está en la raíz del proyecto así que, mientras no diga lo contrario, todos los fragmentos de código deberán picarse en este fichero.

Lo primero que tendremos que hacer proporcionar a Ant los diferentes tasks proporcionados por Cobertura.

<path
      id="cobertura.classpath"> <fileset dir="${cobertura.dir}"> <include name="cobertura.jar" /> <include name="lib/**/*.jar" /> </fileset> </path> <taskdef classpathref="cobertura.classpath"  resource="tasks.properties" />

Esto es uso estándar de Ant. La ruta a la raíz del frameworks lo indicamos en la propiedad cobertura.dir que a su vez cargamos del fichero de propiedades privadas. Usamos el fichero de propiedades privadas (nbproject/private/private.properties) porque la ruta del framework tiene sentido que pueda ser diferente en las máquinas de desarrollo y en el servidor de integración y, recordemos, si tenemos bien montado el repositorio de código el directorio nbproject/private no suele incluirse en el mismo. Para que todo esto funcione deberemos cargar desde el build.xml directamente dicho fichero de propiedades:

<property file="nbproject/private/private.properties"/>

y efectivamente añadir la propiedad en nbproject/private/private.properties :

cobertura.dir=/srv/cobertura

Los pasos para usar Cobertura son los siguientes:

instrumentalizar el código bajo testing,
ejecutar los tests unitarios con JUnit que genera los datos de cobertura y
parsear los datos de cobertura para generar informes.

Instrumentalizar el código

Cobertura (y la mayoría de de frameworks de este tipo) funciona de manera que al ejecutar los tests unitarios se analiza qué parte de las clases bajo testing están siendo accedidas por las pruebas y qué partes no y se vuelca esta información en un archivo. Para que el framework de testing (en nuestro caso JUnit) pueda obtener esta información, Cobertura habrá tenido que instrumentalizar previamente las clases bajo test. Es decir, antes de ejecutar los tests, habremos tenido que permitir a Cobertura que genere un bytecode modificado (instrumentalizado) para cada una de las clases bajo testing. Es un proceso similar a como funcionan algunos profilers . Para obtener las clases instrumentalizadas lo haremos de la siguiente manera:

<target name="cobertura-instrument" depends="compile"> <cobertura-instrument  todir="${cobertura.classes.dir}" datafile="${cobertura.ser.file}" > <fileset dir="${build.classes.dir}"> <include name="**/*.class"/> </fileset> </cobertura-instrument> </target>

Creo que el target se entiende bastante fácilmente: básicamente estamos especificando donde guardaremos las las clases instrumentalizadas ( cobertura.classes.dir ), en qué fichero se escribirán los datos de cobertura ( cobertura.ser.file ) y dónde residen las clases a instrumentalizar ( build.classes.dir ). Esta última propiedad es una de las propiedades estándar que residen en el nbproject/properties ; las otras dos deberemos introducirlas en dicho fichero.

cobertura.ser.file=${build.dir}/cobertura.ser cobertura.classes.dir=${build.dir}/cobertura/classes

Como nuestro target requiere los bytecode de las clases a instrumentalizar tiene como dependencia el target estándar compile que es el que usa NetBeans para compilar el proyecto. Entre las dependencias del propio compile se encuentra el target init que, entre otras cosas, es el encargado de cargar el fichero de propiedades (y por eso nosotros no tenemos que hacer de manera explícita la carga del mismo).

Ejecutar los tests

El siguiente paso consiste en ejecutar los tests sobre las clases instrumentalizadas para así extraer la información de cobertura. Aquí también podemos aprovecharnos de los scripts generados por NetBeans. Nuestro nuevo target , que llamaremos test-cobertura básicamente será una copia del target test (que es el que normalmente usa NetBeans para ejecutar las diferentes tests unitarios) con pequeñas modificaciones. Esta es la pinta que debería tener:

<target name="cobertura-test" depends="set-cobertura-file, init,compile-test, -pre-test-run,cobertura-instrument, -do-test-run,test-report,-post-test-run,-test-browse"> </target>

Con respecto al original, hemos añadido dos nuevas dependencias. Por un lado cobertura-instrument que es una referencia al target anterior para asegurarnos que existen las clases instrumentalizadas. Por otro lado hemos definido otra dependencia a otro target que también debemos construir y que muestro a continuación:

<target name="set-cobertura-file" depends="init"> <property  name="test-sys-prop.net.sourceforge.cobertura.datafile" value="${cobertura.ser.file}"/> </target>

Este target es necesario para establecer un parámetro de sistema que debemos pasar a todos los tasks de JUnit usados en los diferentes targets de los ficheros de scripting incluidos desde el build.xml (en particular el build-impl.xml ). Necesitamos pasar este parámetro para que los tasks del JUnit sepan dónde escribir la información de cobertura mientras ejecuta los tests.

El nombre de la propiedad de sistema a pasar es net.sourceforge.cobertura.datafile el porqué se pasa el parámetro de sistema en una propiedad con un nombre algo diferente, lo tengo explicado en este otro post . El valor de la propiedad, como ya hemos visto (pues es un propiedad que ya he necesitado en targets anteriores), está dentro del fichero nbproject/project.properties y por eso nuestro target tiene una dependencia del target init que es el que se encargaba de cargar las propiedades definidas en ese fichero.

Falta un detalle adicional: especificar al JUnit que ejecute las clases instrumentalizadas y no las generadas directamente en la fase de compilación. Para hacer esto sólo tenemos que introducir unos pequeños cambios en el classpath utilizado por los targets de testing lo que implica cambiar la propiedad run.test.classpath definida en el nbproject/project.properties para que quede así:

run.test.classpath=\ ${cobertura.dir}/cobertura.jar:\ ${cobertura.classes.dir}:\
      ${javac.test.classpath}:\ ${build.test.classes.dir}

Si hemos hecho todo correctamente al ejecutar el target cobertura-test deberían ejecutarse los tests unitarios como siempre pero además debería haberse construido el fichero build/cobertura.ser que contiene la información de cobertura.

Crear los informes de cobertura

El fichero build/cobertura.ser , como decíamos, contiene la información de cobertura pero está en formato binario porque ha tenido que generase en tiempo de ejecución de los tests de manera eficiente. Para extraer información legible hay que parsear dicho fichero. Para ello Cobertura nos proporciona el task cobertura-report .

Este task permite generar los informes en dos formatos: en XML o en HTML . Nosotros generaremos ambos. El primero lo necesitaremos para pasárselo al plugin correspondiente en el Hudson. El segundo nos proporcionará una vista agradable y legible. Veamos el target que tenemos que definir:

<target name="cobertura-report" depends="cobertura-test"> <cobertura-report datafile="${cobertura.ser.file}" format="xml" destdir="${cobertura.report.dir}" srcdir="${src.dir}" /> <cobertura-report datafile="${cobertura.ser.file}" format="html" destdir="${cobertura.report.dir}" srcdir="${src.dir}" /> </target>

Creo que aquí no hay mucho que explicar. Defino dónde está el fichero que contiene la información de cobertura, dónde quiero generar los informes y el formato de los mismos. Como siempre habremos de definir la propiedad cobertura.report.dir en el nbproject/project.properties :

reports.dir=${build.dir}/reports cobertura.report.dir=${reports.dir}/cobertura-report

Si ahora ejecutamos este target deberían generarse los informes en el directorio especificado. Si le echamos un ojo a los informes de tipo HTML vemos que básicamente ha generado unas páginas al estilo de la documentación de las API pero con la información de cobertura. Una manera muy útil e intuitiva de mostrar la información.

Configurar el Hudson

Una vez hemos configurado todo lo anterior, ya tenemos hecho el trabajo duro. La configuración del Hudson, afortunadamente, es bastante sencilla. Estos son los pasos:

instalar Cobertura,
instalar el plugin de Cobertura y
configurar el job :
1. configurar el workspace para indicar dónde está Cobertura,
2. añadir el cobertura-report en la lista de targets que tiene que ejecutar el Ant y
3. configurar el directorio donde están los informes en XML

Instalar Cobertura

Para que el Ant lanzado por Hudson al construir el proyecto sea capaz de instanciar los tasks del Cobertura, éste tendrá que ser instalado en la máquina donde reside Hudson. El proceso de instalación será exactamente análogo al que hemos hecho en el entorno de desarrollo: descargar el paquete, descomprimirlo en el directorio /srv y establecer un enlace simbólico.

Instalar el plugin

Una vez tenemos Hudson instalado, añadir plugins es trivial. Desde la interfaz web vamos a Hudson -> Manage Hudson -> Manage Plugins -> Available y entonces seleccionamos Hudson Cobertura plugin y le damos a Install . El asistente entonces instala el plugin tras los cual habrá que reiniciar Hudson.

Configurar eljob

Aquí estamos presuponiendo que ya existe un job previo correctamente configurado y al que simplemente vamos a añadir el soporte de cobertura. Si no fuera así, echadle un ojo a este otro post que ya publiqué en su momento.

Lo primero que haremos es configurar el workspace para que sea capaz de encontrar Cobertura durante la fase de construcción del proyecto. Para ello, nos vamos al directorio nbproject/private/private.properties del job correspondiente y añadimos la propiedad que indica dicha ruta:

cobertura.dir=/srv/cobertura

A continuación modificaremos los targets de Ant que usa Hudson para construir el job . Si tuviéramos el target test lo eliminaríamos y a continuación añadiremos el target cobertura-report .

Lo siguiente es configurar el plugin para que utilice el informe XML generado:

Publish Cobertura Coverage Report : activamos la opción para que Hudson muestre la información de cobertura.
- Cobertura xml report pattern : build/reports/cobertura-report/coverage.xml
  Aquí ponemos la ruta al fichero donde hemos generado el informe en formato XML.
- Coverage Metric Targets : este apartado nos permite definir las métricas a partir de las cuales la construcción del job se considera estable o no.

En principio ya está todo. Ahora podríamos lanzar una construcción para comprobarlo. Si todo va bien, Hudson mostrará los informes de cobertura bajo el enlace Coverage Report en la raíz del job .

- 8 -

Tagged: Agile, calidad, Hudson, Java, NetBeans

Bits y Bytes » NetBeans: Pasar propiedades de sistema a los tasks JUnit de los scripts de NetBeans

Fri, 06 Feb 2009 19:59:46 +0000

Como ya he explicado alguna vez, NetBeans utiliza scripts de Ant para realizar las diferentes tareas que lleva acabo el IDE, como compilar el proyecto, lanzar los tests, ejecutarlo, desplegarlo, etc.

NetBeans genera los scripts de manera modular de manera que el usuario pueda personalizarlo de forma adecuada. Genera el build.xml principal en la raíz del proyecto que a su vez incluye otros tantos recursos del subdirectorio de nbproject. Estos recursos son ficheros de propiedades y de scripting adicionales con la implementación real de los diferentes targets.

La idea de esta estructuración es que los ficheros con targets en el directorio nbproject (build-impl.xml, por ejemplo) nunca deberían tocarse ya que se pueden regenerar (y por tanto se perdería toda nuestra personalizacion) en función de las diferentes opciones que definamos para nuestro proyecto a través de la propia interfaz del IDE. Por contra, el build.xml principal no se regenerará y es por tanto en este fichero donde personalizaremos los scripts (añadir nuevos targets, definir propiedades, etc.).

El problema surge cuando queremos modificar el comportamiento de algunos de los targets definidos en los ficheros “intocables”. Por ejemplo, un requerimiento que puede surgir fácilmente (veremos algún ejemplo en próximos posts) es la necesidad de pasar parámetros de sistema a los tasks que ejecutan las pruebas unitarias con JUnit.

Afortunadamente el equipo de NetBeans ha previsto esta situación y la solución es bastante sencilla. Imaginemos que queremos pasar una propiedad de sistema que se llama MiPropiedad con valor MiValor, la solución pasa por definir en el build.xml una propiedad que se llame test-sys-prop.MiPropiedad y todos los taks Junit de los scripts generados automáticamente recibirán la propiedad MiPropiedad con el valor que le hayamos indicado. Si necesitáramos pasar más de una propiedad repetiríamos el mismo proceso con otro nombre de parámetro.

En código, habría que incluir el siguiente tag en el build.xml principal:

<property name="test-sys-prop.MiPropiedad" value="MiValor" />

Si queréis entender el motivo exacto y hackear los scripts de NetBeans, echadle un ojo a este post.

Tagged: Ant, JUnit, NetBeans

Bits y Bytes » NetBeans: Monitorizar Hudson desde NetBeans

Fri, 06 Feb 2009 17:30:01 +0000

En un post anterior explicaba como montar un entorno básico para poder empezar a trabajar en un entorno TDD. El ide que elegí fue NetBeans y el servidor de integración continua Hudson. El siguiente paso natural es poder monitorizar Hudson desde el propio NetBeans sin tener que abrir el navegador web. Para poder llevar a cabo esta tarea, existe un plugin desarrollado por el propio equipo de Hudson. Aunque su uso es muy sencillo, en este post explicaré cómo instalarlo, configurarlo y utilizarlo. Los desarrolladores del plugin tienen un entrada en su wiki, así que mi post es un poco redundante

Instalar el plugin

El primer paso consiste en instalar el plugin. Para ello tenemos varias alternativas.

Podemos descargarlo desde el NetBeans Plugin Portal como un fichero nbm que luego instalaremos a través del gestor de plugins del NetBeans: Tools -> Plugins -> Downloaded -> Add Plugins y seleccionaremos el fichero descargado.

La otra alternativa, que prefiero, es hacerlo directamente desde la pestaña de plugins disponibles siempre que tengamos configurado el Update Center del Plugin Portal : Tools -> Plugins -> Available Plugins -> Install .

Configurar el plugin

Una vez instalado lo tenemos disponible en la pestaña Services junto con los servidores, los SGBDs y demás, valga la redundancia, servicios.

Haciendo click derecho sobre el icono del Hudson, nos aparece la opción de añadir una instancia (podríamos monitorizar simultáneamente diferentes servidores de integración). Simplemente tendremos que completar el asistente dándole un nombre a esa instancia, asignándole la url donde reside el servidor y una frecuencia de refresco del estado del mismo.

Usar el plugin

A partir de ese momento podemos ver el estado de Hudson de un vistazo. Por un lado podemos ver el estado de todos los jobs con códigos de colores (correcto, roto o inestable) y el estado de ocupación de la cola de construcción. Por otro lado podemos programar nuevas construcciones de cualquier job haciendo click derecho sobre el job -> Start job o ver una información más extendida del job haciendo doble click sobre el mismo (lo que abre una ventana en el panel del editor). Obviamente podemos saltar directamente a la página web correspondiente en el navegador haciendo click derecho sobre el nodo correspondiente -> Open in Browser .

El “problema” de monitorizar de esta manera es que nos fuerza a acceder a la pantalla de servicios. Afortunadamente el plugin también proporciona una alerta a manera de iconito rojo parpadeante y estresante en el margen inferior izquierdo del NetBeans. El icono omnipresente persiste hasta que se arregle el job roto. Clickando sobre el mismo nos da información del job (o jobs ) que están causando la alerta.

Disfrutadlo.

Tagged: Hudson, NetBeans

Vida amarilla: Programar en PC-BSD con Netbeans IDE

Mon, 26 Jan 2009 22:04:31 +0000

Autor: Miguel A. Cruz. C. (miguelcrux [a] gmail [dot] com) Fecha: 19 setiembre del 2007Gentil colaboración para PC-BSD Perú: http://www.pcbsd-pe.orgParte de NetBeans Blogging Contest siteLo que es Netbeans 6.1 beta Netbeans es un IDE para el desarrollo de aplicaciones basadas en Netbeans Plataform. Netbeans es muy extensible: posee un constructor de interfaces gráficas llamado Matisse, soporte

My Travels: Reflections on the lake

Mon, 19 Jan 2009 15:51:53 +0000

Consectetuer arcu ipsum ornare pellentesque vehicula, in vehicula diam, ornare magna erat felis wisi a risus. Justo fermentum id. Malesuada eleifend, tortor molestie, a fusce a vel et. Mauris at suspendisse, neque aliquam faucibus adipiscing, vivamus in. Wisi mattis leo suscipit nec amet, nisl fermentum tempor ac a, augue in eleifend in venenatis, cras sit id in vestibulum felis in, sed ligula. In sodales suspendisse mauris quam etiam erat, quia tellus convallis eros rhoncus diam orci, porta lectus esse adipiscing posuere et, nisl arcu vitae laoreet.

Zelus torqueo velit ad suscipit vindico luptatum premo. Ut metuo suscipere autem suscipit si fere facilisi abluo ille. Mos duis, rusticus facilisis inhibeo suscipit loquor indoles, sagaciter opto capto, premo. Regula os, ea zelus torqueo ideo, consectetuer, iustum jugis. Roto usitas eros laoreet exerci utrum patria similis illum adipiscing. Ulciscor, tation utinam ut molior et, te in aliquip. Nostrud nostrud ratis antehabeo incassum jus abdo vicis adipiscing nostrud.

Dignissim hendrerit similis amet quis abico oppeto appellatio conventio suscipit haero commodo.

Bits y Bytes » NetBeans: Montando un entorno de integración continua (Hudson + Ant + SVN + NetBeans)

Mon, 12 Jan 2009 18:24:45 +0000

Este post como artículo en PDF

Introducción

Cuando uno lee posts, libros y escucha experiencias de la aproximación ágil al desarrollo del software y empieza a profundizar y a aprender conceptos tales como el TDD (test driven development) y la integración continua, se le despiertan una ganas irrefrenables de empezar a trabajar de este modo. En este post lo que intentaré explicar es cómo montar un entorno sencillo que nos permita tener los cimientos de un sistema ágil que cada uno podrá extender para satisfacer sus propias necesidades. Como se menciona en este post, tres de los pilares de la integración continua son: un repositorio de datos, un servidor de integración continua y una herramienta que permita automatizar la construcción de la aplicación. Yo además añadiría un cuarto: un IDE que se integre bien con el resto del entorno. No es el propósito de este post discutir la utilidad de estos componentes (el post mencionado anteriormente puede ser un buen punto de partida para los recién llegados), sino elegir unas herramientas concretas y describir su configuración e integración. En mi caso he hecho la siguiente elección (que no tiene por qué ser la única ni la mejor):

repositorio de código: SVN
servidor de integración continua: Hudson
herramienta de construcción: ANT
IDE: NetBeans 6.5

Por simplicidad he distribuido el entorno entre una máquina Linux (Ubuntu 8.10) con IP 192.168.1.10 (dato que es relevante para tareas de configuración que iremos viendo) que actúa simultáneamente como repositorio de datos y de integración continua y un número arbitrario de máquinas de desarrollo (también Ubuntu 8.10) que contienen los IDE’s y el entorno con el que trabajan los desarrolladores. En cualquier caso, otras distribuciones tienen exactamente la misma complicación y los pasos requeridos son directamente extrapolables y fácilmente adaptables. Para explicar los diferentes pasos utilizaré un mismo ejemplo ya que considero que hablar con algo concreto suele ser más sencillo, tanto para el que explica como para el que intenta entender, que hacerlo en general o en abstracto. Presupongo la inteligencia de los potenciales lectores para hacer las adaptaciones requeridas en cada punto a sus propias necesidades. No es muy relevante, pero utilizaré un proyecto personal que estoy empezando estos días que sirve para hacer un seguimiento de las valoraciones de mis cursos y que se titula, en un alarde de originalidad, “Encuestas”.

En el siguiente diagrama muestro el entorno que acabaremos montando. Las rutas que aparecen en el servidor no tenemos por qué entenderlas ahora pero servirán como referencia a medida que vayamos construyendo la solución.

Configuración Subversion

He elegido Subversion porque es un repositorio más o menos potente que supera algunas de las limitaciones de nuestro querido y viejo CVS y aún a día de hoy es una de las herramientas que, bajo mi humilde opinión, están más extendidas en la industria. No voy a entrar en los detalles de instalación y de configuración del propio Subversion. Para ello ya hay mucha documentación online (por ejemplo aquí). Me centraré en la creación de un repositorio para nuestro proyecto. Es cierto que se puede usar el mismo repositorio para más de un proyecto, pero yo prefiero tenerlo separado (alguno de los motivos aparecerán más adelante, aunque también se puede justificar razonadamente la otra postura).

Crear el repositorio del SVN que almacenará el proyecto

Como decía, presupongo que el servidor que actuará como repositorio de datos tiene instalado el Subversion y sus herramientas administrativas (si no es así, nuestro querido apt-get o Synaptic vendrán a nuestro rescate). Lo primero que hay que hacer es determinar en qué ruta almacenaré el repositorio. Yo tiendo a almacenar los diferentes repositorios de cada uno de los proyectos bajo una misma raíz y así mantengo el servidor más o menos organizado. La ruta también debería ser vistosa porque luego formará parte de la configuración que utilicen los clientes (como los IDE’s) para conectarse con dicho repositorio. Trabajando con Ubuntu, y si hemos instalado el Subversion desde paquetes, se crea un usuario svn. Para que todo funcione de manera correcta, deberíamos asegurarnos que el propietario del repositorio es este usuario. Una manera de hacerlo es ejecutar los comandos de administración del Subversion con este usuario y otro es cambiar después el propietario del directorio (y su contenido) con el comando chown (chown -fR svn .)/Encuestas-2). En definitiva, para crear el repositorio haremos lo siguiente:

svnadmin create /srv/svn/Encuestas-2

El directorio /srv/svn es la raíz de todos mis repositorios y Encuestas-2 es el que usaré para este proyecto en particular. Si ahora nos situamos en en el ese directorio y hacemos un listado deberíamos ver (más o menos) lo siguiente:

ivan@hargon:/srv/svn/Encuestas-2$ ls -alh total 36K drwxr-xr-x 7 svn root 4,0K 2009-01-11 10:43 . drwxr-xr-x 6 svn
      root 4,0K 2009-01-11 10:43 .. drwxr-xr-x 2 svn root 4,0K 2009-01-11 10:43 conf drwxr-xr-x 2 svn root 4,0K 2009-01-11 10:43 dav drwxr-sr-x 5 svn root 4,0K 2009-01-11 10:43 db -r--r--r-- 1 svn root 2 2009-01-11 10:43 format drwxr-xr-x 2 svn root 4,0K 2009-01-11 10:43 hooks drwxr-xr-x 2 svn root 4,0K 2009-01-11 10:43 locks -rw-r--r-- 1 svn root 229 2009-01-11 10:43 README.txt

Establecer la seguridad del repositorio

Cuando se crea un repositorio en el Subverson es, obviamente, para que los desarrolladores puedan utilizarlo. Por tanto un paso importante es la parte de securización y autorización del mismo: establecer quién podrá acceder y sus credenciales. Subversion tiene diferentes mecanismos de autenticación y de transporte seguro de la información (incluyendo ssh). No voy a entrar en los detalles y explicaré cómo hacerlo de la manera más sencilla. Para más información os remito al anterior enlace.

En mi caso, todas las máquinas residen en el interior de mi red de área local, que puede considerarse “zona segura”. Un punto importante es que los mecanismos de seguridad (y otros más) se establecen por repositorio (en contraposición a una configuración global para todos ellos) lo que nos permite que convivan repositorios con diferentes configuraciones (este es uno de los motivos por los que prefiero tener un repositorio por proyecto). Lo primero es determinar el modo de autenticación. Para ello habremos de editar el fichero

/srv/svn/Encuestas/conf/svnserve.conf

para que quede más o menos así:

[general] anon-access = none auth-access = write password-db = passwd realm = My Realm

De hecho estas opciones seguramente preexisten en el fichero generado en el repositorio y lo único que habrá que hacer es descomentarlas. También es posible que en el fichero haya otras tantas opciones comentadas que no vamos a necesitar para nuestra configuración básica, así como diferentes comentarios descriptivos. Yo los he obviado por claridad. Con esta configuración lo que estamos haciendo es decirle al Subversion que busque los usuarios y las credenciales en un fichero de texto plano. El siguiente paso, precisamente, consiste en configurar qué usuarios y con qué credenciales podrán acceder al repositorio editando dicho fichero que se encuentra en:

/srv/svn/Encuestas/conf/passwd

que editaremos para que quede algo parecido a lo siguiente:

[users] ivan = super-secret-passwd ana = top-secret-passwd

Estos serán los usuarios y passwords que habrá que configurar en los clientes (en nuestro caso usaremos NetBeans).

Configuración NetBeans

Supongamos que nuestra aplicación de ejemplo Encuestas es una aplicación web típica que va a correr encima de un Tomcat 6. Así pues lo primero que haremos es crear un nuevo proyecto web mediante los asistentes del IDE. Asumo que estos pasos los sabréis llevar a cabo pero, en cualquier caso, no son el tema del presente post y lo pasaré muy rápido.

Conexión con el Subversion

Una vez tenemos creado el proyecto web, lo siguiente es enlazarlo con el Subversion. Para ello haremos click derecho en el nombre del proyecto, y en el menú versioning seleccionaremos la opción Import into Subversion Repository que nos abrirá un asistente para configurar la conexión. En mi versión de NetBeans (la 6.5) el aspecto que tiene es el que podéis ver en la siguiente captura de pantalla.

Los siguientes pasos nos permiten seleccionar qué ficheros importar al repositorio. En este punto se podría abrir una discusión sobre si sólo subir los ficheros de código y recursos necesarios para el proyecto desde un punto de vista de independencia del IDE utilizado o si bien subir también los ficheros y recursos asociados al IDE. Puede ser una discusión interesante, pero la dejaremos para otro momento. En esta ocasión, para simplificar (y en mi caso es siempre la opción preferida), subiremos todos los recursos tal y como muestra el tercer paso del asistente.

En este momento ya tenemos conectado el IDE con el repositorio. Los pasos e ideas fundamentales son los mismos para otros entornos como Eclipse y CVS. Quizá en otro post puedo explicar cómo configurar alguna de estas otras opciones. Para utilizar el NetBeans como cliente de Subversion tan sólo hay que hacer click derecho sobre el recurso correspondiente (un directorio o un fichero) y elegir la opción Subversion del menú contextual. La siguiente captura de pantalla lo ilustra.

Tests unitarios con JUnit en NetBeans

En posts siguientes explicaré cómo integrar en el entorno ágil que estamos montando diferentes herramientas que aumenten nuestra productividad y la calidad de nuestro código ( PMD, CheckStyle, FindBugs, herramientas de cobertura…), pero por el momento me centraré en aquellas herramientas mínimas que requiere un entorno ágil que quiera trabajar con TDD: test unitarios. La idea es la siguiente: imaginemos que queremos trabajar con el framework de tests unitarios JUnit. Instalaríamos la herramienta en tres “lugares”:

Como plug-in del IDE, lo que permite un uso integrado en el entorno de desarrollo del programador, con todas la ventajas de uso que ello conlleva.
Como target en el build.xml del Ant. Este target nos permitirá ejecutar las mismas tareas desde la línea de comandos sin ayuda del IDE pero además, y más importante, permitirá al servidor de integración continua lanzar la tarea y generar los diferentes informes (en el caso de JUnit serán ficheros XML) especificando qué tests han sido superados, cuáles han fallado, etcétera.
Como plug-in (que a veces puede venir preinstalado) del servidor de integración continua (en nuestro caso Hudson), de manera que pueda utilizar los informes generados en el target del Ant para mostrar información útil y gráfica y determinar si la construcción ha fallado o no entre otras cosas.

En este apartado veremos el primer punto y el resto los iré desarrollando a lo largo del post. También os aconsejo que leáis este magnífico post sobre cómo usar JUnit en NetBeans del propio blog oficial del IDE. El plug-in de JUnit ya está instalado por defecto en la mayoría (si no en todas) las distribuciones de NetBeans como IDE Java. Incluye además las dos versiones que se utilizan hoy día (la familia 3.X y la familia 4.X). Yo personalmente me decanto por la versión 4 porque me gusta poder utilizar anotaciones. Al crear cualquier proyecto Java con los asistentes de NetBeans, éste ya está preconfigurado para utilizar el framework (aunque nosotros podamos ignorarlo). Lo podéis comprobar en dos sitios: por un lado en la ventana Projects podemos ver que se ha creado un directorio Test Packages y por otro lado si hacemos click derecho sobre el nombre del proyecto, y abrimos el diálogo Properties en la sección Libraries – Compile Test veremos que están están agregadas las bibliotecas correspondientes.

La manera de construir un test unitario con NetBeans es muy simple. Simplemente tenemos que seleccionar la clase que queremos testear, hacer click derecho, seleccionar Tools y finalmente Create JUnit Tests que lanzará un menú modal en el que podremos seleccionar qué código autogenerar en el unit test que se va a crear (en el primero unit test que creemos, el entorno nos preguntará qué versión de JUnit querremos usar y ya la mantendrá para el resto del proyecto).

Una vez codifiquemos el test unitario, lo siguiente es poder ejecutarlo; nada más sencillo: Run -> Test Project (o la combinación ALT + F6) y el resultado indicando si se pasan o no los tests se mostrará por la consola del IDE.

Configuración del Ant

Supongo que en este punto no tengo que explicar qué es Ant y asumo que conocéis su funcionamiento. Si bien trabajando en local, el IDE puede hacernos transparentes todos aquellos aspectos engorrosos como configurar el CLASSPATH, compilar, generar documentación, correr herramientas de análisis, desplegar en el servidor de aplicaciones, etcétera, cuando tenemos que hacerlo de manera remota, o hacer el despliegue en producción, o automatizar cualquiera de estas tareas dentro de un script, o, lo que más nos interesa en este post, permitir a un servidor de integración continua que construya nuestro proyecto, necesitamos una herramienta independiente del IDE. Ant es una opción que nos permite llevar esto a cabo (otra opción, por ejemplo, sería Maven).

Trabajando con Eclipse, hasta donde llega mi conocimiento, no tenemos más remedio que construir los build.xml a mano. De todos modos una vez que se ha hecho uno, si se organiza y parametriza de forma adecuada, el resto de proyectos pueden ir reutilizando una misma “plantilla” con cambios mínimos.

Trabajando con NetBeans podemos tener parte del trabajo resuelto. Ello se debe a que todas las tareas que realiza el IDE (compilar, testear, configurar los diferentes CLASSPATH, desplegar, etc.), lo hace con Ant mediante ficheros build.xml (y otros ficheros auxiliares) que construye dinámicamente en función de lo que nosotros configuremos de manera gráfica en la interfaz de NetBeans o a través de cualquiera de sus asistentes. Nosotros podemos aprovecharnos de estos ficheros generados para utilizarlos desde fuera del IDE para nuestros propios propósitos. La propia estructura de los scripts preveen diferentes targets “hook” donde añadir nuestro propio scripting si el generado no es suficiente.

A primera vista esto podría parecer genial y bueno, en gran parte lo es, pero hay que tener en cuenta una serie de consideraciones. La principal es que los scripts generados no son totalmente independientes del IDE ni de la máquina en la que se han generado porque utilizan recursos (bibliotecas y tasks) que sólo existen en los directorios de instalación del IDE y algunas de las rutas generadas son absolutas y por tanto dependientes de la máquina en donde se generaron. Por tanto si estos ficheros quieren utilizarse en otro contexto habrá que hacer algunos ajustes a mano. Dependiendo del tipo de proyecto en el que estemos trabajando (no será lo mismo una aplicación JSE que una aplicación J2EE con dependencias de un servidor de aplicaciones) la cantidad de esfuerzo requerida para hacer los scripts portables será mayor o menor. En este post se muestran algunos de los perfiles de aplicaciones y sus posibles problemas y soluciones (se corresponde con una versión de NetBeans algo vieja, pero la mayor parte de lo que se explica todavía aplica a las versiones actuales).

NetBeans genera el build.xml en la raíz del proyecto. Si lo abrís podéis ver que básicamente es un script vacío que lo que hace es importar otros tantos ficheros (más o menos dependiendo del tipo de proyecto) que se encuentran en la subcarpeta nbproject. NetBeans utiliza esta carpeta como su directorio de trabajo y para contener los diferentes metadatos del proyecto. En principio no deberíamos tocar ninguno de los ficheros contenidos bajo esta jerarquía de directorios a no ser que sepamos exactamente lo que estamos haciendo. Dentro de nbproject tenemos otra carpeta especial: private. Deberemos ir con cuidado de no incluir esta carpeta en el repositorio (por defecto el asistente ya lo hace bien) ya que contiene ficheros de parámetros con paths absolutos y dependientes de la máquina de cada desarrollador (o servidor de integración) usados por, entre otras cosas, por los scripts de Ant. Esto será parte de lo que tendremos que replicar a mano en el servidor de integración adaptándolo adecuadamente. (pero ya lo veremos más adelante).

Al abrir el build.xml desde el propio NetBeans, la ventana Navigator nos muestra las tareas disponibles. Si queréis detalles, investigad un poco, pero bueno tenemos todos aquellos targets que esperaríamos encontrar y que podemos necesitar (y muchos más), por ejemplo:

clean
compile
debug
dist
javadoc
test

Los incrédulos podéis abrir una consola y comprobar como podéis invocar las tareas desde la línea de comandos. Para ello sólo os tenéis que situar en el directorio raíz del proyecto y ejecutar el ant como lo haríais con cualquier otro build.xml.

Configuración Hudson

Sólo resta la última pieza del puzle: automatizar la construcción del proyecto desde nuestro servidor de integración continua (Hudson) conectándolo al repositorio. También explicaré como automatizar el hecho que se programe una nueva construcción automática cada vez que hay un commit en el repositorio. La instalación y configuración inicial de Hudson es trivial pero está fuera del ámbito de este tutorial (baste decir que básicamente consiste en desplegar un war en un servidor de aplicaciones o un contenedor web como Tomcat).

Automatización de la construcción

Hudson automatiza la construcción de proyectos en lo que denomina j obs, así pues un mismo proyecto software puede tener diferentes jobs. Por ejemplo, tener configurado un job que se ejecute cada vez que se haga un commit en el repositorio y que lo único que compruebe es que el proyectos es compilable y que se pasan los test unitarios y tener otro job programado para ejecutarse tres veces al día para correr tests de aceptación o de integración más pesados. Nosotros empezaremos por algo muy sencillo, configurando un job para que haga lo que explicaba en el primer ejemplo (compilación más tests unitarios).

Hudson tiene una interfaz muy sencilla de utilizar. A diferencia de otros servidores de integración, tanto la creación como la configuración de los jobs se hace íntegramente desde la interfaz web.

Para crear nuestro job haremos click en New Job y se iniciará el asistente de creación. Lo primero que tenemos que hacer es dar un nombre a nuestro job que será utilizado tanto en la interfaz e internamente en el servidor de integración. Se puede utilizar cualquier símbolo en el nombre e incluso espacios, pero yo prefiero (manía personal) utilizar nombres con una sola palabra porque cuando luego se quiere navegar “a mano” (mediante la consola) por los jobs siempre es más cómodo no tener espacios puesto que el nombre que usemos se corresponderá con el nombre del directorio donde residirá toda la información asociada a dicho job. En nuestro ejemplo: Encuestas-2. Lo siguiente es elegir el tipo de job que estamos construyendo; nosotros construiremos un job estándar que es lo que Hudson llama un Build a free-style software project. Lo seleccionamos y le damos a OK para ir a la siguiente pantalla del asistente. En esta nueva pantalla tenemos todos los elementos de configuración del job que rellenaremos (aquéllos que haga falta) como sigue:

Source Code Managment: Subversion
- Repository URL: svn://192.168.1.10/srv/svn/Encuestas-2/Encuestas
  Aquí hay que tener en cuenta una cosa. La raíz del repositorio es Encuestas-2 pero configuramos la url hasta Encuestas . Si no fuera así, el workspace generado para construir este job tendría un subdirectorio Encuestas (lo que complicaría la configuración del resto de elementos del job )
Build Triggers: permite definir en qué momento Hudson tiene que construir el proyecto. Hay diferentes políticas con las que podéis experimentar. Nuestro propósito para este job es que se construya cada vez que hay modificaciones en el repositorio. Para implementar esta política hay dos posibles maneras: o bien Hudson va preguntando al repositorio “¿ha habido cambios en el código?” de forma periódica (lo que se conoce como mecanismo por encuesta y que se corresponde con la opción “poll”) o bien que el propio Subversion avise a Hudson cada vez que ha habido un cambio. Esta última aproximación es más eficiente (y a mí parecer más elegante), pero se trata más bien de una configuración del Subversion (que veremos más adelante) y no del Hudson. Así pues no activaremos ningún tipo de trigger (lo dejamos tal y como está).
Build: nos permite configurar cómo Hudson debe construir el proyecto. Existen diferentes mecanismos pero nosotros en este post vemos cómo se hace mediante Ant, así que será esta la opción que elegiremos.
- Ant version: dejaremos la “Default” con lo que Hudson utilizará la versión que encuentre en el path (esto está presuponiendo que existe un Ant configurado correctamente en la máquina donde reside Hudson).
- Targets : compile test javadoc
  Aquí tendremos que especificar los targets definidos en el build.xml que queremos que Hudson ejecute. Como estamos utilizando el build.xml automáticamente generado por NetBeans tendremos que tener en cuenta algunas consideraciones que explico más adelante (como había comentado el build.xml generado no es del todo independiente del NetBeans y habrá que poner algún parche para que funcione desde Hudson).
Publish Javadoc : marcamos esta opción para publicar los documentos generados por javadoc asociados a nuestro proyecto. Los javadoc se generarán porque hemos definido el target correspondiente en la sección previa.
- Javadoc directory :Encuestas/dist/javadoc
Publish JUnit test result report : marcamos esta opción para publicar los informes (y gráficas) de los resultados producidos por los diferentes test unitarios creados en el proyecto.
- Test report XMLs : Encuestas/build/test/results/*.xml

Configurar el workspace del Hudson y añadir dependencias externas al Subversion

Hudson almacena todos los ficheros que necesita para su funcionamiento así como los diferentes artefactos para cada uno de los job en un directorio raíz conocido como el HUDSON_HOME. No es el propósito de este artículo explicar cómo configurarlo, pero puesto que necesitaremos modificar algunos aspectos de nuestro job sí que necesitamos saber cuál es su valor. Para verlo, desde la página principal de Hudson accedemos al menú de configuración y es el primer parámetro que nos encontramos (Hudson Home -> Manage Hudson -> System Configuration -> Home directory). En mi caso es el siguiente

HUDSON_HOME = /srv/hudson_home

Dentro de este directorio existe el subdirectorio jobs que contiene una entrada para cada job configurado. Así pues aquí tendremos un subdirectorio Encuestas-2 (que, como decía, se corresponde con el nombre que le asignamos al job cuando lo configuramos previamente). Dentro del directorio correspondiente a cada job, uno de los subdirectorios es workspace (si no existiera, le daríamos a construir el job desde la interfaz del Hudson). Este directorio contiene los ficheros descargados desde el repositorio de código cada vez que se lanza una construcción del job (el código fuente, los ficheros a usar por Ant, las bibliotecas incluidas en el proyecto, etc) y los artefactos generados en la construcción del proyecto. Lo remarco de nuevo: contiene los ficheros descargados desde el repositorio. Lo que quiere decir que si el proyecto para ser construido necesita artefactos que existen en los entornos de desarrollo pero que no están incluidos en el repositorio (o sus localizaciones son diferentes a las especificadas en los diferentes scripts de construcción), la construcción inevitablemente fallará. Con las herramientas con las que estamos trabajando habrá que hacer lo siguiente:

opcionalmente, si es un proyecto J2EE o requiere bibliotecas externas al contenido del repositorios de código, hacerlas accesibles al Hudson,
añadir algunas otras dependencias de NetBeans que tiene el build.xml generado,
construir el directorio /nbproject/private y su contenido para solucionar las dependencias.

Nuestro proyecto es un proyecto web que hemos configurado de manera que haga uso de la implementación de Servlets de Tomcat. Ello significa que en nuestro entorno de desarrollo tenemos un Tomcat y por tanto tendremos que replicar su instalación en la máquina donde reside Hudson para que pueda usar dichas bibliotecas. Lo más sencillo es empaquetar el Tomcat instalado en uno de los entornos de desarrollo y desempaquetarlo tal cual en el servidor de integración. En mi caso lo situaré en /srv/apache-tomcat-6.0.18.

La manera más sencilla de solucionar las dependencias que tienen los scripts del Ant del NetBeans es seguir una aproximación similar a la del caso del servidor de aplicaciones: copiar el propio NetBeans en la máquina donde reside el servidor de integración para que éste tenga acceso directo a todos los recursos. Obviamente es posible usar una aproximación menos “drástica” y copiar sólo aquellos recursos necesarios, pero sin duda copiar todo el entorno es la manera más rápida que hacerlo y la única penalización que obtenemos es ocupar unos cuantos MB más en el disco duro. Personalmente prefiero “malgastar” esos pocos a MB a tener que estar hackeando los scripts para ver qué necesito exactamente o pelearme con posibles y sutiles errores difíciles de trazar. Recapitulando: empaquetaremos el NetBeans de una de las máquinas de desarrollo y en mi caso lo situaré en /srv/netbeans-6.5. Adicionalmente NetBeans también guarda parte de la configuración en un directorio oculto en el home del usuario en un directorio oculto llamado .netbeans (esto es útil para que diferentes usuarios en una misma máquina física puedan tener configuraciones diferentes). En este caso no será necesario copiarlo absolutamente todo (un poco más adelante daré los detalles).

A continuación hemos de construir el directorio private que contiene los metadatos donde, entre otras cosas, se está configurando parte de la información local a utilizar por Ant y que por ello no se ha incluido en el Subversion. El tipo de proyecto que estamos usando (proyecto web usando Tomcat) sólo genera un fichero en esta carpeta, build.properties . Construiremos la carpeta private como un subdirectorio de la carpeta nbproject y copiaremos el fichero properties de uno de los entornos de desarrollo.

Los cambios que aplicaremos (todos relacionados con el cambio de rutas absolutas diferentes en desarrollo y en integración) son los siguientes:

cambiar la ruta al Tomcat por la que corresponde (sustituir la cadena /home/ivan/apache-tomcat-6.0.18 por la cadena /srv/apache-tomcat-6.0.18),
cambiar la ruta del Netbeans (sustituir la cadena /home/ivan/.netbeans-6.5 por la cadena /srv/netbeans-6.5),
cambiar las referencias al directorio de configuración del home (sustituir la cadena /home/ivan/.netbeans por /srv/.netbeans).

La primera línea del nbproject/private/ properties pasará a referenciar al archivo de configuración del Tomcat a la nueva ubicación en el servidor de integración en la ruta /srv/.netbeans/6.5/tomcat60.properties . Editaremos el fichero para adaptarlo al nuevo entorno; de hecho realmente la única línea que habremos de modificar es la que define el directorio donde reside el Tomcat porque el resto sólo tienen sentido si queremos arrancar el propio Tomcat (circunstancia que se da en las máquinas de desarrollo pero no, en principio, en el servidor de integración). Tras modificar el fichero tendríamos algo así:

tomcat.home=/srv/apache-tomcat-6.0.18 tomcat.password=super-password-de-administracion-de-Tomcat tomcat.url=http://localhost:8084
      tomcat.username=ide

Otro fichero referenciado en el nbproject/private/ properties que también tendemos que modificar será el /srv/.netbeans/6.5/build.properties . Este fichero gestiona una gran cantidad de propiedades. Afortunadamente con sólo sustituir todas las ocurrencias de la cadena que indica la ruta de la raíz de la instalación del NetBeans por la nueva ruta en el servidor de integración será suficiente (en mi caso, sustituir /home/ivan/netbeans-6.5 por /srv/netbeans-6.5 ).

Comprobando que el job está bien configurado

¡Felicidades! El camino ha sido más o menos largo y tedioso (no tanto, ¿verdad?), pero ya hemos casi terminado.

Para asegurarnos que todo se ha configurado correctamente intentaremos construir el proyecto desde la consola del servidor de integración. Para ello nos situaremos en el directorio Encuestas dentro del workspace del job que estamos configurando (/srv/hudson_home/jobs/Encuestas-2/workspace/Encuestas) que define la raíz del proyecto tal y como está en el Subversion. En ese directorio tenemos el build.xml así que podemos invocar al Ant tranquilamente. Una buena idea es probar todos los targets que querremos ejecutar desde el Hudson ( compile, test y javadoc ). Si se ejecutan sin problemas tenemos la garantía que Hudson también podrá hacerlo.

La prueba de fuego será construir el job desde la interfaz del Hudson: Hudson Home -> Encuestas-2 -> Build Now lo que programa una ejecución. Al terminar la misma, tendremos una nueva entrada en la Build History que tendrá una bullet azul o roja en función de si el proyecto se ha podido construir de forma correcta o de si ha habido algún error.

Los links Javadoc y Latest Test Result nos permiten acceder respectivamente a la documentación del proyecto y a los informes de testing generados por los diferentes tests unitoarios (Junit).

En este punto no estaría de más hacer una copia de seguridad del directorio nbproject/private y todo su contenido. El resto del workspace lo podéis regenerar al momento desde el repositorio, pero los cambios que habéis aplicado a los ficheros contenidos en el private no los tenéis en ningún otro sitio. Puesto que a priori, como decía, podemos recuperar (casi) todo el workspace desde el Subversion, en según qué circunstancias podemos decidir borrarlo sin acordarnos de todas las modificaciones que hemos tenido que hacer manualmente.

Conexión con el SVN

Podríamos dejarlo aquí, pero uno de los requisitos que queríamos configurar es que el job se construyera automáticamente cada vez que hiciéramos un commit en el Subversion. Para conseguir este comportamiento tenemos que configurar el Subversion para que avise al Hudson cada vez que detecte esta situación.

Una de las características que tiene Hudson es que permite programar la construcción de un job haciendo una petición GET sobre una url asociada al proyecto en cuestión. Siguiendo con nuestro ejemplo dicha url sería http://192.168.1.10:8180/hudson/job/Encuestas-2/build.

Por otro lado, el Subversion prevee una serie de eventos que pueden ser detectados y asociarles un script. Tenemos una serie de plantillas de los scripts y eventos que se pueden detectar en la carpeta hooks del repositorio que estamos utilizando. Puesto que nosotros queremos activar la construcción del proyecto cada vez que hacemos un commit, el script que necesitamos codificar es uno que se llame post-commit:

svn@hargon:/srv/svn/Encuestas-2/hooks$ ls post-commit.tmpl post-unlock.tmpl pre-revprop-change.tmpl post-lock.tmpl pre-commit.tmpl pre-unlock.tmpl post-revprop-change.tmpl pre-lock.tmpl start-commit.tmpl svn@hargon:/srv/svn/Encuestas-2/hooks$ cp post-commit.tmpl post-commit svn@hargon:/srv/svn/Encuestas-2/hooks$ chmod ug+x post-commit

El fichero que hemos copiado es una simple plantilla. Ahora la editaremos para que efectivamente haga una petición GET . Esto lo podemos hacer de múltiples maneras, aunque una muy fácil es utilizar Perl y algunas de sus bibliotecas (el gestor de paquetes apt-get o Synaptic nos permitirá instalar todas las bibliotecas requeridas de una manera sencilla ). Una posible implementación de este script es la siguiente:

#!/usr/bin/perl use LWP::Simple; use HTML::LinkExtor; my $content = get("http://192.168.1.10:8180/hudson/job/Encuestas-2/build");

Comprobemos que el script funciona ejecutándolo desde la consola. Si todo va bien, al abrir el Hudson veremos que se ha lanzado una construcción del job.

El último paso es probar que la integración con el Subversion funciona correctamente. Simplemente tenemos que hacer un commit que modifique cualquier fichero y el Hudson debería construir el job.

ACTUALIZACIÓN: 2ª Parte – Añadir métricas de cobertura de código de los tests unitarios

ACTUALIZACIÓN: 3ª Parte – Métricas de calidad con NetBeans y Hudson

Tagged: Agile, Ant, Hudson, Integración Continua, Java, JUnit, NetBeans, SVN, TDD

Avbravo: Unete al NetBeans Community Docs en Español

Wed, 07 Jan 2009 14:14:12 +0000

Este año 2009, es un año interesante de muchos cambios y actividades. A finales del 2008 el Programa Community Docs se ha hecho multilingue (Ingles, Alemán y Español)

Entre algunos de los proyectos que podemos ampliar, serian la creación de documentos sobre NetBeans, y enlazarlos en el wiki de NetBeans Community Docs en Español, en este enlace. http://wiki.netbeans.org/CommunityDocs_ES.

Aquí puedes compartir con otros miembros de la comunidad tus conocimientos sobre Java y NetBeans, como lo han hecho Diego Silva y Luis Enrique LeFunes, eres bienvenido a la comunidad en español.

Le Funes » NetBeans: Generando el SerialVersionUID de una clase desde NetBeans

Tue, 06 Jan 2009 00:15:02 +0000

Anteriormente vimos como generar el serialVersionUID de una clase mediante el comando serialver. Ahora veremos como generar el mismo valor desde NetBeans IDE haciendo uso del plugin serialVersionUID generator for netbeans 6.5. Instalación Ver actualización al final del post Para instalarlo tenemos que seguir unos simples pasos: Descargar el plugin según la versión del ...

Avbravo: T-shirt NB 10 años

Mon, 22 Dec 2008 16:45:53 +0000

Hace unos dias me llego el T-shirt conmemorativo de los 10 años de NetBeans.

Avbravo: NetBeans 7.0 Milestone 1

Sat, 20 Dec 2008 02:26:12 +0000

Ya esta disponible NetBeans 7.0 Milestone 1, sin duda una versión muy previa del IDE, pero sin lugar a dudas permite conocer algunas de las nuevas caracteristicas.
Estas invitado a descargarla, e iniciar tus pruebas

Aqui tenemos el RoadMap

Avbravo: Woodstock migra a ICEface

Thu, 18 Dec 2008 00:38:49 +0000

Desde hace unos años, cuando se libero Java Studio Creator, el desarrollo de aplicaciones JSF poseia un diseñador visual, algunos recordaran los problemas iniciales de JSC, consumo excesivo de recursos, y algunos problemas con los componentes, esto fue rapidamente solucionado, luego llego la migración a NetBeans, mediante Visual Web Pack, un paquete de componentes que dotaba al IDE de un diseñador Visual para JSF, al cabo de un tiempo y de muchas mejoras, contamos con los componentes Woodstock, que ofrecian un conjunto de componentes muy utiles para nuestras aplicaciones.
Recientemente el proyecto Woodstock, no seguira , y por lo tanto existen muy buenos recursos para continuar con el desarrollo de aplicaciones Web, una de ellas es ICEFaces.
La comunidad NetBeans esta colaborando con la comunidad ICEFaces para facilitar la migración de Woodstock a ICEFaces.

Página de migración de Woodstock a ICEfaces
Descargar el Pluging ICEfaces desde ICEfaces.org, o desde NetBeans Update Center seleccionando Tools -> Plugins desde el IDE NetBeans
Lea Guía de Woodstock a ICEfaces
Lea Matriz de migración de componentes Woodstock a ICEfaces
Unase a Foro de migración de Woodstock a ICEfaces

Programa en Java y disfruta de un café lojano » Java – Netbeans: JavaFX Picture Puzzle una aplicación JavaFX para Facebook

Wed, 10 Dec 2008 02:02:06 +0000

Via un RSS de Sun, me he enterado de la existencia de una aplicación Java desarrollada para Facbook, bueno hasta ahí ninguna novedad. Lo interesante es que ha sido desarrollada utilizando JavaFX.

Detallando un poco la aplicación: se trata de un Puzzle o rompecabezas, que se forma a partir de una imgén que es tomada de tú album de fotos. Para ver en funcionamiento dicha aplicación debes buscar JavaFX y el segundo link te mostrará ésta aplicación, luego sigues los pasos que se muestran y estarás disfrutando de ésta aplicación.

Ésta aplicación, podría ser la primera aplicación JavaFX, que se lanza a producción y que tiene miles de usuarios potenciales. Lamentablemente para quienes estamos utilizando Ubuntu y no tenemos instalado el jre6u10 esté mundo FX está aún lejano. (No instalo el jre6u10, porque no aparece en Synaptic)

Avbravo: Conferencia NetBeans en Panamá

Tue, 09 Dec 2008 14:12:52 +0000

Hace unas semanas participe de una conferencia en la Universidad Nacional de Panamá, donde hable sobre NetBeans en la educación, y mi amigo Eivar hablo sobre Ubuntu.

Programa en Java y disfruta de un café lojano » Java – Netbeans: Sun lanza la plataforma JavaFX

Fri, 05 Dec 2008 21:29:47 +0000

Revisando el sitio de Sun he podido ver cómo se hace el lanzamiento de la plataforma JavaFX, para la cual han creado un sitio, en el cual pueden ver vídeos, descargar el SDK, ver ejemplos y demos de lo que se puede hacer con ésta plataforma para la construcción de interfaces de aplicaciones.

Adicionalmente la gente de NetBeans anunció (y me enteré vía correo) que se puede actualizar la versión 6.5 para soportar JavaFX, aún no sé si con un editor visual o a puras sentencias.

Esperemos y veamos como se adopta ésta nueva tecnología.

Héctor: GOOGLEMAPS + PHP + NETBEANS

Thu, 04 Dec 2008 21:39:34 +0000

Tenia un proyecto para desarrollar un sitio, el cual termino muy bruscamente :( pero bueno ya ni modo.

En este proyecto tenia la idea de hacer uso de los google maps pero no me quede con las ganas de al menos hacer una pequeña implementacion, se requiere, de PHP, Apache, netbeans y el API Key para poder hacer uso del google maps.

Se inicia un nuevo proyecto y en "source folder" yo coloque la ruta al directorio de apache, despues indican la URL del proyecto (debe de ser "visible" por apache) con esto tendremos el proyecto creado, ahora viene lo mas complicado, Busca la pestaña de "Services" busca "getGoogleMap" y arrastralo dentro del <body></body>

<html> <head> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> <title></title> </head> <body> Colocar el "getGooogleMap" aqui </body> </html>

Despues extienden "Source Files"/org_netbeans_saas_google" en el estara el archivo "GoogleMapsServiceProfile.php" y en el colocan el APY Key, en la variable $apiKey.
Unos pequeños cambios y se tendra esto:

Que facil es con Netbeans

NETBEANS AN ADAPTIVE POWERFUL IDE: Nuevas características en MySQL 5.1

Sat, 29 Nov 2008 04:19:44 +0000

Particionamiento. Que permite distribuir porciones de tablas en el sistema de archivos, de acuero a reglas las cuales pueden ser establecidas cuando la tabla es creada. 
Replicación a nivel de fila. Originalmente se utilizan para la propagación de sentencias SQL dentro de un clúster de servidores de datos. 
API de plugins. Ahora que está de moda el hacer extensibles nuestras aplicaciones por medio de módulos o plug-ins, esta capacidad es ahora introducida a MySQL para permitir la carga de componentes al motor de la base de datos sin necesidad de reiniciarlo. 
Agenda de eventos. Tal como los servicios cron en UNIX, ahora es posible disparar sentencias almacenadas de acuerdo a un evento originado por tiempo, de esta manera se pueden ejecutar tareas diariamente, mensual, anual, por las noches, por las mañanas, o el momento de configurarlas. 
Tablas de log. Ademas de tener la posibilidad de que el servidor lleve un registro en archivos log de las sentencias ejecutadas, tenemos la características de definir tablas log para optimizar su búsqueda y análisis.

Esto por solo mencionar algunas de sus recientes características, pero no están por de más, las mejoras realizadas al módulo de clúster, backup de espacios de tablas, funciones XML utilizando XPath, (aunque para mi gusto le faltó soporte para XQuery).

Muchas felicidades al equipo de MySQL (ahora división de Sun) por esta nueva liberación que esperabamos con ansias.

Avbravo: Visita de Bruno Souza en Panamá

Mon, 24 Nov 2008 02:10:58 +0000

Tuvimos la visita en Panamá de un gran amigo y figura muy importante de Sun Microsystem, Bruno Souza, quien asistio a una serie de reuniones y conferencias para hablar sobre Java, NetBeans, Open Source.

Algunas Fotos

Asistentes a las conferencias en Chitre

Avbravo: Bruno Souza en Panama

Mon, 24 Nov 2008 02:10:30 +0000

Pronto tendremos la visita de Bruno Souza en Panamá.

Bruno Souza es Director de las Comunidades Open Source en Sun Microsystems, donde se centra en el crecimiento y el apoyo de todo el mundo al movimiento de código abierto. Conocido como el brasileño "JavaMan", Bruno es un evangelista de Java y de open source que ha sido el fomento de la mayoría de las comunidades en su carrera profesional.

En Sun, Bruno era el Administrador de la Comunidad NetBeans y también apoya los grupos de usuarios OpenSolaris . Como fundador y coordinador de SouJava (la Sociedad de Usuarios de Java) que trabajan con Java y muchos grupos de usuarios, Bruno a ayudado a impulsar el crecimiento de la Comunidad de Grupos de Usuarios en todo el mundo.

Es un desarrollador de Java desde los primeros días de la tecnología Java, Bruno participó en algunos de los mayores proyectos de Java en Brasil y tiene cientos de presentaciones de nivel internacional.

Bruno es también Director de la Open Source Initiative donde se discute la evolución del movimiento open source. Cuando no está delante de un ordenador, Bruno disfruta de su tiempo con su familia en un pequeño escondite cerca de Sao Paulo.

Open Source InitiativeOpen Source Initiative.

El OSI esta activamente involucrado en construir comunidades Open Source y en la educación. Los miembros del OSI frecuentemente viajan por todo el mundo dictando conferencias sobre el Open Source, asistiendo a eventos y reuniones con gobiernos, ejecutivos de entidades publicas y privadas acerca del uso de la tecnología, licencias, las ventajas de este modelo para la economía y la educación.

Bruno se ha reunido con importantes empresas y gobiernos a nivel mundial, recientemente estuvo reunido con el presidente Lula Da Silva en Brasil , conversando sobre este modelo.

Le Funes » NetBeans: Agregando tareas al script de ANT en un proyecto de NetBeans

Sat, 22 Nov 2008 08:14:23 +0000

Si queremos agregar tareas adicionales al script de ANT que NetBeans genera para un proyecto ,por ejemplo para actualizar archivos, generar ejecutables, etc. , primero que nada deberemos entender donde NetBeans organiza las tareas de compilación, empaquetamiento, generación de javadoc, etc. NetBeans genera dos archivos de ANT: nbproject/build-impl.xml build.xml Podremos verlos desde la ...

Avbravo: Nuevo Miembro de la comunidad NetBeans en Español

Sun, 02 Nov 2008 17:00:17 +0000

Sin duda, la comunidad NetBeans en Español crece constantemente, y se mantiene colaborando para unir a muchos paises de habla hispana, y ofrecerles una herramienta y documentación en su idioma.
Presentamos a Albert , el hijo de nuestro amigo Amaury, quien es un gran colaborador.

Me comenta Amaury que Albert seguira sus pasos desde Cuba, colaborando con la traducción de NetBeans y aportando a la comunidad.

Avbravo: NetBeans 6.5 RC2 en Español en Ubuntu 8.10

Sat, 01 Nov 2008 03:29:08 +0000

Ayer fue el lanzamiento de Ubuntu 8.10 , coincidencia con la liberación de NetBeans 6.5 RC2 en español, asi que procedi a instalarla:
Proceso de instalación

El IDE en ejecución

Avbravo: NetBeans 6.5 RC2 en Español

Thu, 30 Oct 2008 16:00:44 +0000

Ya esta disponible para descarga NetBeans 6.5 RC2 en Español.
Anuncio en el blog de Masaki
Sin duda un gran esfuerzo de la comunidad hispana.
Los módulos disponibles son platform, javase.
Los demás se descargaran desde el Update Center a medida que se terminen.
Página de descarga
http://bits.netbeans.org/netbeans/6.5/community/rc2/ml/

Seleccionar los paquetes

Proceso instalación

Terminación de la instalación

Iniciando el IDE

IDE

Avbravo: Project WebSynergy

Wed, 29 Oct 2008 16:04:14 +0000

Es un interesante proyecto de Sun, que puedes probar basado en Liferay Portal Server, GlassFish v3, y MySQL.

Página Oficial

Un tutorial sencillo

Avbravo: Prueba la traducción de NetBeans 6.5

Thu, 23 Oct 2008 19:05:20 +0000

Pronto estara disponible la versión 6.5 de NetBeans, te invitamos a realizar las pruebas necesarias, aqui encontras un tutorial de los pasos para relizarlo.
http://wiki.netbeans.org/AvbravotutorialLocalizaciones

Pueden reportar los errores en el wiki.

Avbravo: NetBeans IDE 6.5 RC1 Download Started

Tue, 21 Oct 2008 15:58:54 +0000

Ya esta disponible para su descarga la versión NetBeans IDE 6.5 RC1
puedes descargarla desde este sitio.

Avbravo: Community Docs

Mon, 20 Oct 2008 15:02:20 +0000

Contribuye con los tutoriales en Community Docs.
Es importante aportar con documentos de manera que ayuden a otras personas.
La comunidad es un gran lugar donde tenemos acceso a mucha información valiosa, pero es más importante lo que puedas contribuir en base a tus conocimientos y experiencias.

Wiki Community Docs
blog

NetBeans Community Docs Blog

Avbravo: Celebrando los 10 años de NetBeans

Mon, 20 Oct 2008 14:48:13 +0000

Celebrating 10 Years of NetBeans!

Puedes participar del Decatlón

Enter the NetBeans Decathlon!

Las reglas son sencillas:
. 10 events, each worth a different amount of points.
.Complete any number of events that tally up to 50 points.
.IMPORTANT: Keep track of links to blog entries, forums, and so on. You will need to submit these links in the Decathlon Entry Form.
. The first 300 participants to complete the Decathlon form will be eligible to receive a limited edition NetBeans 10th Anniversary T-shirt.
. There is no judging, so be creative, reminisce, and have fun!
. The Decathlon ends on Monday, October 27th, 2008.

Programa en Java y disfruta de un café lojano » Java – Netbeans: Movimiento de una cámara de vigilancia desde un celular

Fri, 17 Oct 2008 00:41:33 +0000

: esquema del proyecto

Bueno durante esta secuencia de tutoriales que desarrollaremos en este presente mes les iremos comentando un proyecto que desarrollamos para la materia de ARQUITECTURA DE COMPUTADORES, el tema del mismo fue control de una “Cámara de vigilancia manipulado desde un celular”.

Para el desarrollo del presente proyecto comenzaremos por una descripción breve del mismo, a continuación daremos un poco de marco teórico, aunque un poco aburrida es muy necesaria para el desarrollo del mismo.

Descripción:

Vale mencionar que en sus principios JAVA fue diseñado para la manipulación de componentes electrónicos. Partiendo de estos antecedentes hemos creído conveniente utilizar esta plataforma para realizar el software para este proyecto.

Con el presente tema pretendemos tener una cámara de video, la cual nos va estar trasmitiendo en tiempo real lo que está captando.

Dicha transmisión será visualizada en un computador central. Desde este computador los usuarios podrán cambiar el ángulo de visualización de la cámara para tener un mejor panorama del objetivo. A este servicio de movimiento de la cámara se lo pretende migrar a una aplicación de celular. El usuario se conecta desde el celular al computador, y podrá mover el ángulo de la cámara.

Debido a que por las noches la cámara no se puede visualizar bien el objetivo, se pretende, dependiendo el tiempo contar con un sistema de pretendido automático de las luces del lugar en el cual se encuentra la cámara.

Vale aclarar que en la primera parte del proyecto se va conectar a un computador y en una segunda fase lo migraremos para controlarlo desde un celular.

Para el movimiento de la cámara se construirá una base metálica a la cual le adaptaremos dos cerbos; para tener una manipulación tanto en el eje de la “X” y otro en las “Y”.

Detalles Técnicos:

- La conexión desde la cámara hacia el computador se lo realizara a través de un cable serial.

- La transmisión del video se lo realizara a través de un cable USB, propio de la cámara.

- Además para el control del movimiento vamos a utilizar un micro controlador, el cual interpretara las ordenes desde el computador hacia los motores de la cámara los cuales están encargados de del movimiento de la cámara. Además este controlador esta encardo de la iluminación de la cámara.

Objetivos de este post:

ü Construir un instrumento electrónico que nos permite rotar la cámara, y además permita ser manipulado desde la computadora.

ü Desarrollar un software para la manipulación de la cámara (rotación de la cámara).

ü Además este software permitirá visualizar lo que este transmitiendo lo que capta la cámara.

ü El mismo software deberá receptar las conexiones del celular que se conecte a la maquina central.

ü El software antes mencionado dotarlo de un servicio de mail, para la notificación de alertas a los usuarios.

ü Construir la parte de electrónica para el prendido de luces desde el computador.

Tecnología que se utilizara:

Para el desarrollo del software que estará en la maquina central se lo construirá en la plataforma JAVA.

Para la captación del video desde la cámara se utilizara un api de JAVA llamado “JavaTM Media Framework 2.1.1e”.

Además utilizaremos una librería para el Sistema Operativo Windows Xp, la misma que nos permite transmitir datos atreves de un cable serial o paralelo, el nombre de librería es “COMM.JAR”.

Para la programación del micro controlador se utilizara el siguiente Software: “Vascom-Avr”. En su versión: 1.11.9.1 document build 20.

Un vistazo de este software:

En el presente tutorial pondremos algunas referencias sobre el manejo de este software.

Para la simulación del circuito electrónico, utilizaremos el siguiente software: “Proteus versión 7”.

Un vistazo de este software:

Los elementos que componen nuestro circuito para la manipulación son:

· Micro controlador 16PU

· 6 Leds

· 1 Led de alta luminosidad

· Capacitores de 1 Microfaradio

· 4 Resistencias de 370 ohmios

· Max 232 para trabajar con el puerto serial

· Pulsadores para resetear y enviar mensaje a la computadora

· Cable serial

División de este articulo:

1. Definir tecnologías para el presente proyecto.

2. Desarrollar una simulación del dispositivo.

3. Construir el software para receptar el video en la computadora.

4. Construir el software para manipulación de hardware del circuito electrónico para el movimiento.

5.Construcción de software para el celular.

6.Prueba en un servidor para manipulación desde la web (incluye el servicio mail).

Avbravo: NetBeans Innovators Grant Contest

Fri, 03 Oct 2008 17:10:09 +0000

Hace unos dias se realizo el anuncio oficial de la culminación deNetBeans Innovators Grant Contest

En este caso cree un tutorial de Cube°n, un buen proyecto que nos permite gestionar nuestros proyectos en JIRA o localmente.
Sitio oficial del proyecto
Tutorial Usando Cube°n

{ Radamanthys } » NetBeans: Sacandole el jugo a JCalendar

Fri, 03 Oct 2008 02:46:57 +0000

Una vez agregado JCalendar al classpath del proyecto(no lo voy a utilizar desde el diseñador esta vez xD) me he puesto a trastear con el y utilizarlo en una aplicacion donde el usuario debe llenar un campo de texto de un formulario respetando un formato para la fecha, pero el usuario no debera editar directamente este campo si no que seleccionara la fecha presionando un boton que cargara una ventana tipo pop up, en la cual vera un calendario y un boton de aceptar(que al ser presionado, guardara los datos de la fecha elejida y que posteriormente podemos obtener mediante los metodos que provee la clase(una que me he creado), posteriormente cerrara la ventana).

/* * Clase, uso de JCalendar como una ventana tipo Pop Up * Copyright (C) 2008 Moises Brenes, http://mbrenes.blogspot.com * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by * the Free Software Foundation; either version 2 of the License, or * (at your option) any later version. * * This
      program is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * GNU General Public License for more details. * * You should have received a copy of the GNU General Public License * along with this program; if not, write to the Free Software * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. * * Any non-GPL usage of this software or parts of this
      software is strictly * forbidden. */   package datepicker;   /** * * @author shakka */   public class CDatePicker extends javax.swing.JDialog { private com.toedter.calendar.JCalendar jCal; private javax.swing.JPanel pnlDatePicker; private javax.swing.JButton btnAccept; private String year; private String month; private String day;   public CDatePicker(java.awt.Frame parent) { super(parent, true);   initComponents(); initExtra(); }   public static void main(String args[]) { java.awt.EventQueue.invokeLater(new Runnable() { public void run() { CDatePicker dialog = new CDatePicker(new javax.swing.JFrame());   dialog.addWindowListener(new java.awt.event.WindowAdapter() { public void windowClosing(java.awt.event.WindowEvent e) { System.exit(0); } });   dialog.setVisible(true); } }); }   private void initComponents() { setDefaultCloseOperation(javax.swing.WindowConstants.DISPOSE_ON_CLOSE); setSize(290,275); setModal(true); setTitle("Calendario."); setResizable(false); setLayout(null);   /* Centrar pantalla */ setLocationRelativeTo(null);   pnlDatePicker = new javax.swing.JPanel(); pnlDatePicker.setLayout(null); pnlDatePicker.setBorder(javax.swing.BorderFactory.createEtchedBorder()); pnlDatePicker.setBounds(2, 2, 278, 250); add(pnlDatePicker);   jCal = new com.toedter.calendar.JCalendar(); jCal.setWeekOfYearVisible(false); jCal.setBounds(3, 2, 271, 204); pnlDatePicker.add(jCal);   btnAccept = new javax.swing.JButton(); btnAccept.setText("Aceptar"); btnAccept.setMnemonic('A'); btnAccept.setBounds(3, 206, 271, 32); pnlDatePicker.add(btnAccept);   btnAccept.addActionListener(new java.awt.event.ActionListener() { public void actionPerformed(java.awt.event.ActionEvent ev) { btnAccept_Click(); } } ); }   private void initExtra() { year = new String(""); month = new String(""); day = new String(""); }   public String getYear() { return year; }   public String getMonth() { return month; }   public String
      getDay() { return day; }   public void btnAccept_Click() { year = Integer.toString(jCal.getCalendar().get(java.util.Calendar.YEAR)); month = Integer.toString(jCal.getCalendar().get(java.util.Calendar.MONTH) + 1); day = Integer.toString(jCal.getCalendar().get(java.util.Calendar.DATE));   dispose(); } }

En este metodo de la clase, en la version que utilizo en la vida real hago uso de una clase propia(CPadding) que rellena con ceros a la izquierda los datos miembro de la clase, ya que lo ocupo de esa manera.

public void btnAccept_Click() { CPadding yearPad = new CPadding(Integer.toString(jCal.getCalendar().get(java.util.Calendar.YEAR))); CPadding monthPad = new CPadding(Integer.toString(jCal.getCalendar().get(java.util.Calendar.MONTH) + 1)); CPadding dayPad = new CPadding(Integer.toString(jCal.getCalendar().get(java.util.Calendar.DATE)));   year = yearPad.padLeft('0', 4); month = monthPad.padLeft('0', 2); day = dayPad.padLeft('0', 2);   dispose(); }

Ya en el formulario, el boton que cargara la ventana que contiene el bean calendario lo hara mediante el evento tipico de este componente(click).

/* Evento del boton */ private void btnSel004ActionPerformed(java.awt.event.ActionEvent evt) { /* Se crea la instancia y se hace visible */ CDatePicker dlgDate = new CDatePicker(new
      javax.swing.JFrame()); dlgDate.setVisible(true);   /* Cuando el usuario simplemente cierra la ventana * con boton de cerrar del dialogo, aunque seleccione una fecha * la informacion que obtenemos de la fecha mediante los metodos de la clase * estaran vacios, caso contrario cuando presiona el boton aceptar. */ if (dlgDate.getDay().compareTo("") != 0) {
      txtCampoFecha.setText ( dlgDate.getYear() + "/" + dlgDate.getMonth() + "/" + dlgDate.getDay() ); } }

Mas informacion: http://www.toedter.com