Organizando un entorno de desarrollo libre

[Actualización 081101: Maven2]
[Actualización 081102: TestNG]

Como el movimiento se demuestra andando, he invertido unas cuantas horas en preparar un entorno de desarrollo. En los próximos meses tengo en mente hacer desarrollos en Google App Engine (Python) y también con Seam (J2EE), así que es un buen momento para para probar herramientas diversas. El objetivo es que, asumiendo los costes de instalación y de aprendizaje, el trabajo diario sea sencillo y completo, para lo cual es fundamental la integración de las herramientas.
Consta de los siguientes elementos principales:

Vayamos por partes, indicando brevemente la motivación y las referencias utilizadas.

Kubuntu
Usar GNU/Linux para desarrollo basado en herramientas libres es comodísimo y potente. La instalación de las herramientas viene soportada por APT, y mediante ficheros de configuración y módulos adicionales se puede hacer casi cualquier cosa. Lo he intentado en Windows y no me parece tan sencillo.
(K)Ubuntu porque es amigable con el usuario a la vez que tiene lo bueno de Debian (¡APT!), y no requiere compilar todo como Gentoo. Además, hay muchísima documentación actualizada. Y Kubuntu en vez de Ubuntu porque soy de KDE.

Instalarlo habría sido trivial si no me hubiese empeñado en usar el FakeRAID de la placa (ya que lo pagas...). Seguí las fantásticas instrucciones para instalar Linux Ubuntu 8.04 sobre un FakeRAID que ha compartido Vicente Navarro y no hubo mayor problema.

Repositorio Subversion
En las últimas semanas he sufrido un número ingente de conflictos entre ramas de un proyecto en el que trabajo con CVS, y quiero saber si Subversion ha mejorado algo esto. Aparte de CVS y SVN hay otros muchos SCMs, pero no he querido complicarme más para que el resto de herramientas (Eclipse, Hudson, Trac...) se puedan conectar a él sin problemas.
Apt-get, un poco de configuración en un par de ficheros, y tienes tu servidor SVN montado. Utilicé una guía de SVN en Ubuntu en castellano, y otra en inglés para rellenar los huecos de autenticación de la primera.

Trac
Buscando gestores de incidencias libres los más habituales parecen ser Trac y Bugzilla. Éste segundo tiene fama de monstruoso y complejo de administrar, lo cual no era opción en mi entorno. Trac, por el contrario, es sencillo, lo voy a poder conectar con Eclipse, se conecta al SVN, integra un wiki, es extensible mediante plugins...
Para instalarlo lo obtenemos con apt-get y seguimos la guía de instalación.

JBoss Server 4.2
El desarrollo Java pretendo hacerlo con Seam, que es de JBoss, así que me parece la elección más cómoda. Ya he sufrido el SJSAS/Glassfish, que no tiene por qué ser un mal servidor, pero no lo tienen en cuenta al documentar las librerías, y quiero probar otras cosas. JBoss Server es un servidor completo y con soporte profesional en caso de necesitarlo. Contiene a Tomcat como servidor web. Hice una prueba rápida con Seam en la versión 5 pero el despliegue fallaba, así que he preferido mantenerme en la 4.2, más contrastada.
Tampoco lo he encontrado en repositorios APT, así que a bajarlo a mano. Como pretendo usarlo de desarrollo, lanzado desde Eclipse, ni me molesto en crear el servicio.

Google App Engine
Acostumbrado a J2EE, probar Google App Engine me parece muy interesante para dejar de elegir Java por defecto. Desde que pasé de PHP a Struts no había usado lenguajes de script para desarrollo web.
Todo lo que necesitas saber para comenzar está en el tutorial básico.

MySQL
Profesionalmente siempre había usado Oracle. Al elegir una base de datos libre la elección sencilla es MySQL.
Tanto el cliente como el servidor están en APT, así que la instalación es sencilla.

Eclipse
No hay mucho que decir. No dudo que haya otros también muy buenos, pero Eclipse es el IDE de referencia. Como con SVN o Trac además, no sólo lo elijo por él en sí mismo, sino por su extensibilidad y conectividad.

La última versión es Ganymede. No está en ningún repositorio APT todavía, así que hay que instalarlo tradicionalmente. Inicialmente bajé el paquete J2EE, pero después aparecían problemas de compatibilidad de paquetes de plugins, así que mejor bajar el "clásico" y luego añadirle lo que sea.

Mylyn
Mylyn es una parte de Eclipse que favorece el desarrollo orientado a tareas. Integra en una vista las tareas asignadas, lleva conteo del tiempo empleado, asocia a cada tarea un contexto (para abrir los ficheros interesantes en cada momento) y un largo etcétera. Es algo que puede cambiar la forma de trabajar (¡para bien!). Igual que el Lightroom favorece el flujo de trabajo de un fotógrafo, Mylyn lo hace del programador.
Viene de serie con Ganymede, así que no hay más que hablar.

PyDev
Llevo años con Eclipse y probablemente me quedan unos cuantos más, así que quiero seguir usando ese entorno para programar también en Python. PyDev es el plugin de referencia, y para quien quiera pagar por más, tienen una extensión al mismo.

Hudson
Tras documentarme y ver que no hay uno realmente dominante en el mercado, y que ninguno "lo tiene todo", utilicé esta matriz comparativa de sistemas de integración contínua para elegir el más adecuado. Los más comentados, Cruise Control y Continuum, los descarté por no soportar Trac. Hasta donde sé el tercero en discordia entre los libres es Hudson, que sí tenía todo lo que necesitaba (y también extensible mediante plugins), así que es el elegido. En el libro Java Power Tools (una interesante referencia de herramientas actuales) revisan esos tres junto a LuntBuild.
La "instalación" de Hudson consiste en bajarse el war y ejecutarlo con java -jar hudson.war --httpPort=7777.

Maven
Maven es una herramienta para gestionar varios aspectos de un proyecto: dependencias, compilación, documentación... Se podría ver como un recubriento de Ant orientado a proyectos.
Aparte de las ventajas directas de usarlo, se produce un efecto colateral: el despliegue en un sistema de integración contínua de un proyecto configurado para Maven es trivial (si el sistema de IC lo soporta, claro).
En Kubuntu, con un sudo aptitude install maven2 ya tenemos la herramienta instalada.

TestNG
TestNG es un framework de pruebas que pretende cubrir limitaciones de JUnit a la vez que hacerlo más sencillo. Lo que es más imperioso en nuestro caso, es el framework de pruebas hacia el que está orientado Seam, por lo que será el que usemos.

En próximas entregas, la integración entre ellos.

Posted by Juan Ignacio Sánchez Lara 20:01  

5 Comments:

  1. Miki said...
    Hola Nacho,

    espero con interés la continuación de esta entrada.

    De hecho yo tengo pensado hacer una serie parecida en mi blog.
    jcesarperez said...
    Hola de nuevo Nacho!

    Nosotros tambien estamos probando Ubuntu pero tenemos problemas en convertir a la facción Windows (entre los que me incluyo). Lo cierto es que Eclipse va un poco mejor en Windows, al menos en Gnome.

    A mi también me gustaria comprobar esa ventaja de SVN respecto a CVS para el merge. Me gustaria ver el mismo caso de merge en un sistema y en otro. Para los ficheros binarios está más claro, pero como estamos en LAN y el GB es barato tampoco es critico migrar.

    Trac, Mylin y Hudson son mis 3 ultimos TODOs para este año, espero que me de tiempo. De momento usamos JIRA que tambien se integra fácil, pero no es gratis y no tiene wiki.

    En cuanto a lo python, me has dejado flasheao, ¿ves factible convertir un equipo de programadores Java a python? ¿Contais con algun experto?

    Ya contaras que tal te va...
    Nacho said...
    Ave de nuevo, César! :)

    Pues a mí me pasa lo contrario, me parece que Eclipse (todo, en general) va mejor en Kubuntu. No tengo datos para demostrarlo, quizá es por mi estandarte ^^.

    Lo del SVN es, literalmente, por probar. Yo tampoco migraría. Realmente el problema creo que está en el comparador. Ayer, algo que Araxis Merge veía como una línea añadida Eclipse lo mostraba como 8 de conflicto...

    Así como el entorno Java es una "prueba de concepto" para usarlo "profesionalmente" en cuanto pueda, lo de Python (Google App Engine) es para un proyecto personal. La plataforma (ágil y barata) lo hace perfecto para este caso.
    pelegri said...
    Hola Nacho. Usualmente la gente nos dice que la documentacion de GlassFish es mucho mejor que la de JBoss, pero siempre estamos interesados en dónde fallamos. Si nos das más detalles podremos tratar de mejorar para la próxima. - eduard/o
    Nacho said...
    Hola, Pelegri,

    Mis problemas con Glassfish no han sido por el servidor en sí, sino por la relación de las librerías hacia él: muchas lo ignoran. Un entorno J2EE basado en tecnologías Open Source se basa en multitud de librerías, y que todas ofrezcan documentación y soporte del servidor es muy importante.
    Todas soportan Tomcat y JBoss (éste último, de hecho, es el dueño de una buena cantidad de los productos que usamos), pero no todas SJSAS o Glassfish.
    Por ejemplo, tuvimos un problema entre SJSAS y Spring. El servicio técnico (¡pagado!) de Sun se lavó las manos diciendo que el problema no estaba en sus clases, y los desarrolladores de Spring dijeron que no podían hacer nada, por no tener dicho servidor (de pago).
    Utilizamos otra librería de componentes GIS que ni siquiera tiene dicho servidor entre los soportados...
    Por otra parte, en Eclipse seguimos teniendo que hacer un redespliegue completo cada vez que cambiamos el web.xml o alguna librería (ni siquiera basta con reiniciar). Desconozco si es un problema concreto del servidor o de J2EE.

    Insisto en que SJSAS/Glassfish pueden ser unos servidores fantásticos (supongo que lo serán, si estamos pagando por ellos), símplemente quiero probar otros para ver si nos pueden facilitar el trabajo.

Post a Comment