miércoles, 30 de septiembre de 2009

Usando Hudson como servidor de integración contínua

En el artículo anterior se hizo una descripción de lo que es la integración continua.

Ahora vamos a ver cómo usar Hudson como servidor de integración contínua, para que construya nuestro proyecto de forma automática si hay algún cambio en el repositorio de Subversion y nos informe por email en caso de que se produzca algún error.

En primer lugar, nos descargamos la última versión de Hudson de la web:
https://hudson.dev.java.net/

Nos descargaremos la último versión de Hudson como un archivo .war. Hudson es tan fácil de instalar en un servidor Tomcat cómo copiar el .war en el directorio webapps. Arrancamos el Tomcat y vamos a http://localhost/hudson:

Antes de trabajar con ningún proyecto, vamos a configurar el entorno de Hudson desde Manage Hudson:

Clicamos sobre Configure System:

En nuestro caso, nos interesa configurar Maven y el JDK para que Hudson sea capaz de encontrar sus rutas:

También querremos configurar la notificación por email parapoder enviar correos que alerten sobre construcciones erróneas del proyecto. En caso de no tener un servidor de correo, se puede usar fácilmente Apache James como servidor de correo. Vimos cómo hacerlo en un post anterior.

Una vez tenemos el servidor de correo instalado, podemos modificar la configuración de Hudson:

Ahora podemos crear un nuevo proyecto Java en Eclipse. Para nuestro ejemplo hemos creado un proyecto Maven de una aplicación web y la hemos incorporado a Subversion.

Posteriormente, volvemos a la pantalla principal de Hudson para crear un nuevo job que maneje nuestro proyecto:

Seleccionaremos la última opción Build a maven2 project. A continuación entraremos a la ventana de configuración del proyecto. Configuramos el repositorio de Subversion del proyecto y la consulta de Hudson a este repositorio en busca de cambios que lancen una nueva construcción. Hacemos que esta consulta a Subversion se realice cada minuto:

Ahora lanzamos una construcción de forma manual para construir el espacio de trabajo desde el apartado Workspace del proyecto:

Desde este momento, una vez construido el proyecto, cualquier cambio en el proyecto que sea entregado a Subversion debería reflejarse en una reconstrucción del proyecto. Si subimos una modificación a Subversion, podemos ver cómo Hudson programa una nueva construcción cuando detecta el cambio:


Si ahora introducimos un cambio con un error de compilación, la construcción detectará este error y enviará un correo alertando de este situación:

Con esto, hemos visto cómo configurar y empezar a usar Hudson cocmo servidor de integración continua.

lunes, 28 de septiembre de 2009

Integración continua

Este artículo está traducido y adaptado del siguiente artículo de Martin Fowler en el que expone su idea de lo que es la integración continua:

http://martinfowler.com/articles/continuousIntegration.html

Según Martin Fowler: “La integración continua es una práctica de desarrollo de software en la cuál los miembros de un equipo integran su trabajo frecuentemente, como mínimo de forma diaria. Cada integración se verifica mediante una herramienta de construcción automática para detectar los errores de integración tan pronto como sea posible. Muchos equipos creen que este enfoque lleva a una reducción significativa de los problemas de integración y permite a un equipo desarrollar software cohesivo de forma más rápida.”

Desarrollo mediante integración continua


A continuación se muestra un ejemplo de como incorporar un nuevo desarrollo en un proyecto siguiendo las indicaciones de la integración continua.
  1. Debemos comenzar obteniendo una copia local del código fuente del repositorio de control de versiones, donde se guarda de forma integrada.

  2. Tras obtener la copia local se procede a hacer los cambios necesarios en el código y en los tests de verificación, que se ejecutarán de forma automatizada. Para los tests se suelen usar herramientas de la familia de XUnit.

  3. Una vez finalizados los cambios se llevará a cabo una construcción automatizada en la máquina de desarrollo. Esta fase se encargará de compilar el código, empaquetarlo y realizar las pruebas automátizadas. Sólo si todas estas tareas se realizan sin error se considerará que la construcción ha sido correcta. Si hay errores, habrá que solucionarlos.

  4. Tras una construcción correcta ya se puede pensar en entregar los cambios al repositorio. Puesto que puede haber habido otros cambios por parte de otros desarrolladores mientras se trabaja en local, lo primero será actualizar la copia local y reconstruir el proyecto. En caso de conflicto con nuestros cambios aparecerán errores de compilación o en las pruebas que tendremos que solucionar antes de poder actualizar el repositorio con nuestros cambios.

  5. Una vez entregados los se volverá a construir la línea principal de desarrollo del proyecto en la máquina de integración. Si no hay errores se ya podrá decir que los cambios se han llevado a cabo. En caso de que apareciesen errores, habría que solucionarlos. Esta construcción automática en la máquina de integración puede ser realizada por nosotros de forma manual o de forma automática mediante alguna herramienta.

En caso de que aparezcan conflictos entre desarrolladores, estos serán detectados rápidamente. En este momento lo más importante será solucionar estos errores tan pronto como sea posible.

El resultado de todo esto es un proyecto que funciona correctamente y tiene pocos errores. Todo el mundo desarrolla a partir de un código estable y trata de mantenerse lo más cerca de él como para que las integraciones con él no lleven demasiado tiempo. Se tarda menos tiempo en arreglar errores porque estos aparecen más rápidamente.

Prácticas de integración continua


A continuación se describen las principales prácticas de integración continua:
  • Mantener un único repositorio de código fuente
  • Automatizar la construcción del proyecto
  • Hacer que la construcción del proyecto ejecute sus propios tests
  • Entregar los cambios a la línea principal todos los días
  • Construir la línea principal en la máquina de integración
  • Mantener una ejecución rápida de la construcción del proyecto
  • Probar en una réplica del entorno de producción
  • Hacer que todo el mundo pueda obtener el último ejecutable de forma fácil
  • Publicar qué está pasando
  • Automatizar el despliegue

Mantener un único repositorio de código fuente

Los proyectos de software implican a un montón de ficheros que necesitan ser organizados para construir un producto. Hacer el seguimiento de todos estos ficheros es costoso, sobre todo cuando hay varias personas involucradas. Para facilitar esta tareas han surgido las herramientas de gestión del código fuente o control de versiones, como Subversion o CVS.

Todo se debe incluir en el repositorio. Se debe ser capaz de de construir un proyecto a partir del código descargado del repositorio. También es útil incluir otros recursos como la configuración compartida del IDE. Se recomienda no subir todo aquello que se pueda construir.

Estos sistemas de control de versiones permiten la creación de ramas para el desarrollo. El uso de ramas es problemático y se debe usar lo mínimo posible, como para la corrección de bugs de versiones anteriores o experimentos temporales.

Automatizar la construcción del proyecto

La construcción de un proyecto implica la compilación del código fuente, mover ficheros de un sitio a otro, cargar esquemas en base de datos, etc. Todas estas tareas deberían automatizarse para evitar errores y ganar tiempo.

Existen herramientas como Maven o Ant que permiten esta automatización.

Hacer que la construcción del proyecto ejecute sus propios tests

Dentro del proceso de construcción de un proceso se deberían realizar los tests del código, que pueden implementarse mediante herramientas de la familia XUnit. Estos tests, si están bien hechos, pueden detectar muchos errores.

Entregar los cambios a la línea principal todos los días

La integración permite que los desarrolladores informen unos a otros de los cambios que han hecho. Si esto se hace de forma frecuente, todo el mundo sabrá rápidamente los cambios que se han producido.

El único prerrequisito para que un desarrollador entregue sus cambios a la línea principal es que se pueda construir el código de forma correcta. El desarrollador debe actualizar primero su copia local, resuelve cualquier conflicto y construye su copia local. Si se hace de forma correcta, se subirá a la línea principal.

Haciendo esto de forma frecuente, lo desarrolladores encuentran rápidamente si hay un conflicto y lo arreglan tan pronto lo detectan, cuando todavía es fácil de arreglar. Como mínimo, los desarrolladores deberían entregar sus cambios una vez al día.

Construir la línea principal en la máquina de integración

A pesar de las entregas diarias de los desarrolladores, todavía se pueden producir errores de integración debido a falta de disciplina del equipo o diferencias ambientales entre las máquinas de los desarrolladores.

Para evitar estos errores hay que asegurarse de que se construye el proyecto en la máquina de integración. Es el desarrollador que está haciendo la entrega el responsable de que esta construcción se realice de forma correcta.

La construcción en la máquina de integración se puede hacer de forma manual o mediante un servidor de integración continua como Hudson, CruiseControl, Continuum, etc.

En la forma manual el propio desarrollador lleva a cabo la construcción en la máquina de integración, vigilando su progreso.

Un servidor de integración continua vigila el repositorio y, cada vez que se hace una entrega, para el servidor, recoge el código fuente del repositorio, lo construye y notifica al responsable de la entrega del resultado.

Mantener una ejecución rápida de la construcción del proyecto

Puesto que en un proceso de integración continua lo que cuenta es obtener resultados del proceso tan pronto como sea posible, es preciso que el proceso de construcción no se demore excesivamente.

Normalmente se considera que 10 minutos es un tiempo razonable para la construcción de un proyecto. Si la construcción de un proyecto sobrepasa este tiempo se puede optar por crear varios scripts de construcción, dejando el más sencillo para cuando se quiera hacer una entrega y los más complicados para cuando se deseen hacer pruebas más exhaustivas del proyecto.

Probar en una réplica del entorno de producción

Si estamos probando en un entorno distinto del de producción, cada diferencia es un riesgo de que los que ocurre en desarrollo no ocurra en producción. Para minimizar estos riesgos, se debería usar en ambos entornos el mismo gestor de base de datos, la misma versión del sistema operativo, librerías, etc.

Hacer que todo el mundo pueda obtener el último ejecutable de forma fácil

Todo el mundo que esté involucrado en el desarrollo de un determinado software debería ser capaz de obtener fácilmente el último ejecutable y de ejecutarlo, facilitando las demostraciones, la prueba y la revisión de los últimos cambios.

Publicar qué está pasando

La integración continua considera que la comunicación es muy importante, así que hay que asegurarse que todo el mundo puede ver fácilmente el estado del sistema y los cambios que se han realizado.

Uno de las cosas más importantes que hay que comunicar es el estado de la línea principal de desarrollo. Si se está usando un servidor de integración continua, probablemente se dispondrá de una herramienta web donde se puedan ver los trabajos en progreso en cada momento.

Si se quiere hacer esta información más aparente, se pueden usar los llamados “radiadores de información”, que no son más que elemento visuales como luces o muñecos que informan de un determinado estado. Por ejemplo, se puede usar una luz roja para indicar que se ha producido un error en el servidor de integración continua y una luz verde para cuando no haya errores.

Automatizar el despliegue

Para llevar a cabo la integración continua se necesitan varios entornos como desarrollo, prueba y producción. Ya que se deben mover ejecutables entre múltiples entornos varias veces al día, será mejor hacerlo de forma automática, así que es necesario tener scripts que permitan el despliegue de aplicaciones entre entornos de forma sencilla.

Beneficios de la integración continua


El principal beneficio de la integración continua es la reducción del riesgo. Se puede predecir el tiempo de integración, puesto que es algo que se realiza de forma continua.

También permite reducir la aparición de bugs, puesto que la realización constante de pruebas permite su pronta detección y corrección antes de que entren en producción.

Ya que se dispone en todo momento de ejecutables del proyecto, esto permite la rápida adopción por parte de los usuarios de las nuevas características añadidas al proyecto. Esto también permite que los usuarios valoren estos cambios y sugieran cambios nuevos de forma rápida.

Referencias:
Artículo sobre integración continua de Martin Fowler

viernes, 25 de septiembre de 2009

Manejo de ramas en Subversion desde Eclipse

En este artículo vamos a ver cómo trabajar desde Eclipse con las ramas de desarrollo de un proyecto gestionado en Subversion.

Lo primero que vamos a hacer es crear una rama del proyecto, en la cual podríamos desarrollar una nueva característica del proyecto o corregir un error. Para crear esta rama hacemos clic sobre el proyecto con el botón derecho del ratón y vamos a Team -> Branch/Tag:

Para Subversion es lo mismo una rama (branch) que una etiqueta (tag). Una estiqueta es una rama sobre la que no se incluyen cambios. A continuación seleccionamos el directorio remoto donde se almacenará esta rama. Por convencion, todas las ramas se guardan bajo el directorio branches del repositorio:

Seleccionamos la revisión sobre la que se va a crear la rama. Como queremos que se haga sobre la última versión del desarrollo, seleccionamos la opción por defecto (HEAD):

Por último podemos incluir un comentario e indicar que queremos que nuestra copia local del proyecto se cambie a esta rama para poder desarrollar sobre ella:

Tras esto ya se habra creado la rama, con lo que tendremos la siguiente estructura en nuestro repositorio:

Además, la copia local sobre la que estamos trabajando desde Eclipse habrá pasado a ser la de la rama. Cualquier modificación que hagaos y subamos al repositorio no afectará al trunk del proyecto, sino que solo afectará a dicha rama.

Ahora haremos todas las modificaciones que queramos sobre dicha rama ya las subiremos al repositorio haciendo Commit. Periódicamente deberemos actualizar dicha rama con los posibles cambio que haya podido haber en el trunk, para que nuestra copia no se desvíe del desarrollo principal. Para esto deberemos hacer merges del trunk sobre nuestra rama, haciendo clic con el botón derecho del ratón y yendo a Team -> Merge:

Seleccionamos el tipo de merge que vamos a realizar. Como lo que queremos hacer es actualizar una rama con las modificaciones del trunk, elegimos la primera opción, Merge a range of versions:

Si la copia local no está actualizada saldrá un mensaje para que hagamos un Update. A continuación, elegimos desde donde nos queremos actualizar, que, como hemos dicho, será el trunk:

Hacemos Finish en la siguiente pantalla con las opciones que aparecen por defecto, para que me avise de los posibles conflictos que aparezcan en el merge y me deje decidir:

Si se han hecho cambios en el trunk mientras nosotros trabajabamos en nuestra rama, aparecerán conflictos. La pantalla siguiente nos avisa de que hay un conflicto en una clase que debemos resolver, para lo que se lanzará un editor gráfico:

El editor nos permitirá corregir manualmente los confictos en esta clase:

Una vez corregidos los conflicto, salvamos el fichero y lo cerramos. Aparece la siguiente pantalla:

Indicamos que ya hemos resuelto los conflictos y finalizará el merge:

Cuando hayamos finalizado de trabajar con esta rama habrá que reintegrarla en el trunk haciendo un merge de forma similar. En primer lugar cambiamos la copia local por una vista del trunk:


Después hacemos un merge con la opción Reintegrate a branch:

Seleccionamos la rama que queremos reintegrar:

El resto del proceso es similar a lo anteriormente visto.

Hemos visto cómo trabajar con una rama en paralelo a la línea principal del desarrollo manteniendo la sincronía con ésta y cómo reintegrar esta rama con todos sus cambios a la línea principal.

jueves, 24 de septiembre de 2009

Manejo de Subversion desde Eclipse

En este artículo vamos a ver cómo trabajar con Subversion desde Eclipse. Para ello lo primero es instalar en Eclipse el plugin Subclipse, que podemos obtener de http://subclipse.tigris.org/update_1.6.x:

Una vez instalado este plugin, ya podemos gestionar nuestros proyectos en Subversion desde Eclipse. Lo primero que vamos a hacer es conectar a nuestro repositorio desde la vista SVN Repositories, haciendo New -> Repository Location:

Podemos conectarnos al repositorio en la pantalla siguiente a través de cualquiera de la URL svn://localhost:

A continuación se nos pedrirá el usuario y el password:

Con esto ya habremos configurado nuestro repositorio de Subversion en Eclipse. A continuación crearemos la estructura de directorios en el repositorio, creando los siguientes directorio mediante New -> New remote folder:
  • trunk: Este directorio guardará la línea principal de desarrollo del proyecto.
  • branches: Este directorio guardará las distintas ramas de desarrollo del proyecto.
  • tags: Este directorio guardará marcas asociadas al estado del proyecto en un determinado momento.

Una vez hecha la conexión al repositorio y creada la estructura de éste, vamos a crear un proyecto en Eclipse y subirlo al repositorio. Tras crear un proyecto Java con una clase de prueba, hacemos clic con el botón derecho sobre el proyecto y vamos a Team -> Share project:

Elegimos SVN como el tipo de repositorio:

Indicamos que vamos a utilizar un repositorio ya existente:

Y especificamos la carpeta del repositorio donde se guardará el proyecto:

A continuación podemos introducir un comentario si queremos. Cuando pulsamo Finish nos vamos a la vista de sincronización donde se pueden ver las diferencias entre los archivos que hay en el repositorio y los que tenemos nosotros. Haciendo clic sobre el proyecto con el botón derecho del ratón y pulsando Commit subiremos todos los archivos del proyecto al repositorio:

Tras esto, el proyecto estará incluido en el repositorio y podremos empezar a trabajar en equipo.

Instalación de un servidor de Subversion en Windows

Subversion es un sistema de control de versiones libre y de código abierto desarrollado para subsanar las deficiencias de otro sistema anterior, CVS. Subversion es un sistema genérico de control de versiones que gestiona ficheros y directorios y los cambios hechos sobre ellos a lo largo del tiempo. Esto permite recuperar versiones antiguas de estos ficheros y examinar cómo han cambiado los datos.

A continuación se expone cómo instalar un servidor de Subversion en Windows. Este artículo es una adaptación del siguiente artículo, que a mí me ha sido de gran utilidad:

http://www.jayson.in/programming/eclipse-subversion-and-subclipse-installationintegration-on-windows.html


En primer lugar, descargamos la última versión del servidor de Subversion de Collabnet (en este momento se trata de la versión 1.6.5) de la siguiente URL:
http://www.collab.net/downloads/subversion/

Ejecutamos el instalable descargado y vamos avanzando por las pantallas de configuración que se presentan aceptando las opciones por defecto hasta llegar a la siguiente:

Elegimos el directorio donde queremos que se cree el repositorio. De momento, dejaremos el que aparece por defecto y avanzamos a la siguiente pantalla:

Para evitar posibles conflictos con otros programas, cambiamos el puerto del servidor Apache de Subversion de 80 a 81.

Tras esto, continuamos con la instalación hasta finalizar. Cuando haya terminado el asistente de instalación, comprobamos que el servidor de Subversion está levantado yendo a Panel de Control -> Herramientas Administrativas -> Servicios:

Intentaremos iniciar el servicio. Si aparece algún problema, debemos copiar todos los .dll de la carpeta C:\Archivos de programa\CollabNet Subversion Server en las carpetas C:\ Archivos de programa \CollabNet Subversion Server\httpd\bin y C:\ Archivos de programa \CollabNet Subversion Server\httpd\modules. Ahora ya se debería poder iniciar el servidor sin problemas. Una vez iniciado, probaremos que el servidor funciona abriendo la URL http://localhost:81:

También deberemos arrancar el servicio Collabnet Subversion svnserve para poder conectarnos al repositorio a través del protocolo svn, propio de Subversion.

A pesar de que hemos espeificado en la configuración el fichero donde se creará el repositorio, éste no se encuentra configurado correctamente. Para configurarlo deberemos teclear en la línea de comandos:
svnadmin create “C:\svn_repository”

Tras esto se habrá creado en este directorio una estructura de ficheros. En el directorio conf podemos encontrar los archivos svnserve.conf y passwd, que nos sirven para configurar el acceso al servidor de Subversion.

En el archivo svnserve.conf debemos introducir las propiedades:
anon-access=none
auth-access=write
password-db=passwd

En el archivo passwd introduciremos los usuarios y sus passwords, por ejemplo:
jorge=jorgepassword

Tras esto ya tendremos un servidor de Subversion configurado con el que empezar a trabajar.

lunes, 21 de septiembre de 2009

Crea tu propio repositorio Maven con Apache Archiva

Apache Archiva es una herramienta de gestión de repositorios de artefactos de construcción. Entre otras características, Apache Archiva permite:
  • Crear tu propio repositorio, donde almacenar tus propios artefactos.
  • Hacer de proxy de repositorios remotos, reduciendo el tráfico de red en equipos de trabajo. Cada desarrollador podría descargar los artefactos necesarios de un repositorio de la red local gestionado por Apache Archiva, que sería el que se descargase de los repositorios externos los artefactos necesarios una sola vez.
  • Gestionar la seguridad del repositorio en base a usuarios o roles.

Apache Archiva se puede descargar de dos formas, como un ejecutable o como un war. Por sencillez, usaré el ejecutable.

Una vez descargado el archivo .zip que contiene el ejecutable, podemos descomprimirlo donde queramos. Después, desde el directorio bin de la estructura de ficheros generada, hay que ejecutar la secuencia:
  • archiva install
  • archiva start

Cuando queramos parar, basta con teclear:
  • archiva stop

Con el servidor arrancado, podemos acceder a la interfaz de usuario en la URL http://localhost:8080/archiva. La primera vez que accedamos habrá que crear el usuario administrador. Una vez creado, yase puede empezar a trabajar con la herramienta.

Archiva crea dos repositorios locales, internal y snapshots, que podemos ver en el apartado de administración Repositories:

En el repositorio internal se desplegarán las distribuciones finales de nuestros artefactos, y en snapshots, se despliegaran los artefactos que todavía estén en desarrollo.

Además, también existen otros dos repositorios remotos:

La configuración necesaria para que Apache Archiva pueda hacer de proxy de estos dos respositorios remotos está en el apartado de administración Proxy Conectors:

Cada uno de los conectores tiene la configuración para cada repositorio remoto. En el caso de que nuestra red local accediese a Internet a través de un proxy, habría que configurar nuestro proxy en el apartado Network Proxies y después asignarlo a los repositorios remotos en sus conectores.

Ahora, queremos que nuestros proyectos Maven accedan a los repositorios locales creados pr Apache Archiva, y además, que accedan a los repositorios remotos a través de esta herramienta. Para hacer que Archiva haga de repositorio único para nuestros proyectos Maven, hay que incluir la siguiente configuración en el fichero settings.xml de Maven:
<settings>
...
<mirrors>
<!—- Este es repositorio por defecto -->
<mirror>
<id>archiva.default</id>
<url>http://localhost:8080/archiva/repository/internal/</url>
<mirrorOf>*</mirrorOf>
</mirror>
<mirror>
<id>archiva.apache.snapshots</id>
<url>http://localhost:8080/archiva/repository/snapshots/</url>
<mirrorOf>apache.snapshots</mirrorOf>
</mirror>
</mirrors>
...
</settings>

Si además queremos desplegar nuestros propios artefactos en los repositorios de Archiva, primero tenemos que crear un usuario de Archiva en el apartado User Management de la administración de la herramienta. Para que el usuario que creemos tenga permiso de escritura en un repositorio hay que asignarle el rol de manager en ese repositorio o de forma global para todos los repositorios

Después hay que incluir la siguiente configuración en el fichero settings.xml de Maven:
<settings>
...
<servers>
<server>
<id>archiva.internal</id>
<username>user</username>
<password>pwd</password>
</server>
<server>
<id>archiva.snapshots</id>
<username>user</username>
<password>pwd</password>
</server>
...
</servers>
...
</settings>

Y después incluir la siguiente configuración en el POM de nuestro proyecto:
<project>
...
<distributionManagement>
<repository>
<id>archiva.internal</id>
<name>Internal Release Repository</name>
<url>
http://localhost:8080/archiva/repository/internal/
</url>
</repository>
<snapshotRepository>
<id>archiva.snapshots</id>
<name>Internal Snapshot Repository</name>
<url>
http://localhost:8080/archiva/repository/snapshots/
</url>
</snapshotRepository>
</distributionManagement>
...
</project>

Tras esto, al hacer deploy en Maven de nuestros proyectos, se despliegará en el repositorio de Archiva.

Referencias:
Apache Archiva

Plugin de Maven para Eclipse

Vamos a ver cómo se puede trabajar con Maven desde Eclipse gracias al plugin para Eclipse m2eclipse, que permite, entre otras muchas cosas:
  • Herramienta de configuración del POM de un proyecto Maven.
  • Crear e importar proyectos Maven.
  • Creación de proyectos mediante arquetipos Maven.
  • Gestión gráfica de las dependencias desde Eclipse.
  • Descarga y actualización automática de dependencias.

La instalación se hará desde la herramienta de actualización de software de Eclipse, a la que podemos accedes desde Help → Software Updates → Available Software. Para poder instalar el plugin m2eclipse en Eclipse 3.4, es necesario instalar previamente:
  • Subclipse 1.2: http://subclipse.tigris.org/update_1.2.x
  • Mylyn (Eclipse 3.4): http://download.eclipse.org/tools/mylyn/update/e3.4
  • Mylyn Extras (JIRA Support): http://download.eclipse.org/tools/mylyn/update/extras
  • AJDT (Eclipse 3.4): http://download.eclipse.org/tools/ajdt/34/dev/update

La instalación del plugin m2eclipse se puede hacer desde.
  • m2eclipse Plugin: http://m2eclipse.sonatype.org/update/

Una vez instalado el plugin ya podemos empezar a trabajar con Maven desde Eclipse.

Ahora ya se puede crear un proyecto Maven desde File → New → Other → Maven:

Si seleccionamos Maven Project aparece la siguiente ventana:

En este momento podemos escoger entre crear un proyecto simple o permitir la selección del arquetipo, que nos permitirá crear un proyecto más complejo a partir de un arquetipo de Maven. De momento, crearemos un proyecto simple:

Introducimos la configuración del proyecto, por lo menos el identificador del grupo, el del artefacto, la versión y el tipo de empaquetamiento. Pinchando en continuar se creará un proyecto con la estructura apropiada siguiendo la convención de Maven.

Podemos modificar de forma gráfica el POM de este proyecto haciendo doble clic sobre el archivo pom.xml. Se abrirá el editor gráfico que nos permitirá modificar los diferentes apartados del POM de este proyecto:

Con la realización de ejemplos más complejos veremos las múltiples posibilidades de configuración de proyectos Maven, pero ya hemos vista que con la instalación del plugin m2eclipse disponemos de herramientas que nos permiten la gestión de un proyecto Maven desde Eclipse.

Referencias:
Maven definitive guide

viernes, 18 de septiembre de 2009

Instalación de Maven

En este artículo se expone cómo instalar Maven en nuestro equipo, en nuestra caso, un ordenador con Windows XP. Antes de empezar y como requisito indispensable, es necesario tener instalado un JDK de Java.

En primer lugar, descargamos el archivo zip con los binarios de la última versión de Maven (2.2.1) de lapágina oficial de Maven, y descomprimimos este zip en la ruta que nosotros queramos. En mi caso ésta es C:\java\apache-maven-2.1.1.

A continuación tenemos que definir una variable de entorno llamada M2_HOME que apunta a la ruta donde se encuentran los binarios, es decir, C:\java\apache-maven-2.1.1. También debemos actualizar la variable PATH para que acceda a la carpeta bin de la distribución de Maven, para lo que añadimos la cadena ;%M2_HOME%\bin.

Una vez hecho esto, se puede comprobar la instalación de Maven ejecutando sobre la línea de comandos mvn –v para comprobar que se devuelve correctamente la información sobre dicha instalación:

Tras esto, ya podemos empezar a trabajar con Maven en nuestro equipo. Por ejemplo, podemos crear un proyecto Java simple usando el pugin Archetype de Maven de la siguiente manera:
mvn archetype:generate -DgroupId=com.roldan -DartifactId=prueba -DpackageName=com.roldan.prueba

Al ejecutar esta acción, Maven descarga del repositorio central de Maven en internet todos los artefactos que necesita. Al finalizar tenemos un sencillo proyecto Maven cuyo POM es el siguiente:
<project 
xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.roldan</groupId<
<artifactId>prueba</artifactId>
<packaging>jar</packaging>
<version>1.0-SNAPSHOT</version>
<name>prueba</name>
<url>http://maven.apache.org</url>
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>3.8.1</version>
<scope>test</scope>
</dependency>
</dependencies>
</project>

Al comenzar a trabajar con Maven, se crea un directorio llamado .m2 en el directorio HOME del usuario. En él se encuentra un archivo llamado settings.xml, que sirve para definir las preferencias del usuario respecto a Maven, y un directorio repository, en el que se guardan todos los artefactos que Maven necestita y que han sido descargados del repositorio central.

Ahora ya podemos trabajar con Maven, y en posteriores artículos profundizaremos en su funcionamiento.

Referencias:
Apache Maven
Maven definitive guide

jueves, 17 de septiembre de 2009

Qué es Maven

Maven es una herramienta de gestión de proyectos que se basa en la “convención sobre configuración”. Es decir, asume un comportamiento por defecto que permite empezar a trabajar sin necesidad de configuración. Por ejemplo, Maven asume la estructura de los ficheros del proyecto, con lo cual a la hora de compilar no se pierde tiempo indicando donde se encuentra el código fuente o las librerías como en Ant.

Maven define, entre otras cosas:
  • Un modelo de objeto del proyecto.
  • Un sistema de gestión de dependencias.
  • El ciclo de vida del proyecto.
  • La lógica para ejecutar nuevas tareas en determinadas fases del ciclo de vida.


Modelo de objeto del proyecto (POM – Project Object Model)

EL POM describe todas las propiedades del proyecto. Entre la información que encontramos en el POM se puede destacar:
  • Coordenadas del proyecto: es la información que permite identificar de forma única a un proyecto.
  • Propiedades administrativas del proyecto: licencia, miembros del proyecto.
  • Dependencias del proyecto: puede referirse a otros proyectos.
  • Repositorios remotos: se pueden referenciar repositorios de artefactos Maven, de los cuales los proyectos pueden obtener sus dependencias.
  • Plugins de terceros: permiten añadir al proyecto funcionalidad específica para su desarrollo.

La existencia del POM permite:
  • Reutilización universal de la lógica de construcción: puesto que los plugins trabajan sobre el POM, éstos pueden ser reutilizados ya que no hay dependencias de la localización del proyecto.
  • Portabilidad e integración de herramientas: todos los IDEs tienen ahora un lugar común donde buscar información sobre el proyecto.
  • Búsqueda y filtrado sencillo de artefactos del proyecto: exiten herramientas de gestión de repositorios que pueden usar la información almacenada en el POM para buscar e indexar los elementos de un repositorio.


Sistema de gestión de dependencias

A través del POM se conocen las dependencias de un proyecto. A su vez, estas dependencias pueden tener más dependencias definidas en sus respectivos POM, que se llaman dependencias transitivas. Maven se encarga de recoger automáticamente todo el árbol de dependencias de un proyecto, liberando de esta gestión al desarrollador.

Ciclo de vida del proyecto

Maven define las sucesivas fases del ciclo de vida de un proyecto, de modo que para poder ejecutar una fase, se deben poder ejecutar de forma ordenada todas las fases anteriores del ciclo de vida. Por ejemplo, antes de poder empaquetar un proyecto, debe ser posible compilarlo y realizar pruebas unitarias.

Lógica para ejecutar nuevas tareas en determinadas fases del ciclo de vida

Maven delega gran parte de su responsabilidad en plugins de terceros que intervienen en el ciclo de vida del proyecto. Estos plugins se encargan de compilar, empaquetar o crear sitios web con información sobre el proyecto. La inteligencia de Maven se encuentra en estos plugins, que pueden ser descargados del repositorio de Maven.

Conclusión

Maven es una herramienta que facilita la gestión de proyectos en varios sentidos, entre los cuales cabría destacar:
  • Define una estructura genérica del proyecto, reutilizable por los distintos IDEs.
  • Estandariza las fases del ciclo de vida de los proyectos, de forma que se puede trabajar de la misma forma en cualquier proyecto.
  • Facilita la gestión de dependencias, eliminando la necesidad de recuperarlas de forma manual.

Referencias:
Apache Maven
Maven definitive guide