SpringIDE, plugin de Spring para Eclipse

1. Introducción

En adictosaltrabajo os hemos ido presentando diversos plugins para eclipse (como éste para maven o éste para subversion). Esta vez le toca el turno a SpringIDE, un plugin que os ayudará a desarrollar con Eclipse aplicaciones que utilicen Spring.

2. Entorno

• Debian GNU/Linux 4.1 (Lenny)
• JDK 6 Update 1
• SpringIDE 2.0.2 RC1
• Eclipse 3.3 (Europa)

3. Instalación

Para instalar el plugin vamos a utilizar el gestor de actualizaciones de Eclipse. Es por ello que lo primero que debemos hacer es ejecutar Eclipse.

Una vez lo hayamos arrancado deberemos ir al apartado ‘Help > Software Updates > Find and Install‘ para acceder al gestor de actualizaciones de Eclipse.

Indicamos que queremos instalar nuevas caracteristicas.

Nos aparecerá una pantalla similar a esta. Vamos a instalar el plugin de Spring desde un repositorio remoto, asi que pinchamos sobre ‘New Remote Site’

Y una vez ahi damos de alta un nuevo repositorio, lo llamamos springide e indicamos que la URL donde se ubica es http://springide.org/updatesite

Una vez hayamos dado de alta el repositorio nos aparecerá una pantalla como la anterior, seleccionamos solo el repositorio springide y pulsamos ‘Finish’. Tras eso nos aparecerá una ventana como la siquiente. Marcamos las opciones indicadas en la captura de pantalla y pulsamos sobre ‘Next >’

En caso de estar conforme con las licencias las aceptamos y seguimos

Esperamos a que se instale el plugin. Tardará más o menos en función al ancho de banda del que dispongamos.

Una vez descargado lo instalamos con ‘Install All’ para no tener que ir aceptando los jar del plugin uno por uno.

Y tras eso os aconsejo reiniciar Eclipse para que se apliquen los cambios correctamente y asi no tener problemas.

4. Funcionamiento del plugin

Como habeis podido ver la instalación del plugin es muy sencilla, y ya os adelanto que el uso del plugin también lo es, ya que sus funcionalidades básicas son:

• Crear proyectos con naturaleza Spring, esto es, crear un proyecto y a la vez indicar que ese proyecto está utilizando Spring. Para ello en Eclipse debemos ir a ‘File > New > Project’ y utilizar la caja de texto ‘Wizards:’ para encontrar lo que buscamos con mayor comodidad.

Tras eso, igual que con todos los proyectos de Eclipse, deberemos indicar un nombre para el proyecto. Una vez hecho esto ya habremos creado un proyecto que Eclipse entenderá que es un proyecto con naturaleza Spring. La ventaja que tiene crear un proyecto con esta naturaleza es que gracias al plugin podremos ver fácil y gráficamente qué dependencias tienen unos beans con otros entre otras cosas, pero el cómo hacer eso lo veremos más adelante en el tutorial. De momento pulsamos ‘Finish’ para terminar de crear el proyecto.

• También podemos Indicar, para los proyectos que tienen naturaleza Spring, en qué ficheros xml van a estar declarados los bean de Spring y poder crearlos fácilmente. Para ello hacemos click con el boton derecho del raton sobre el proyecto, y seleccionamos ‘New > Other …’. Como comenté anteriormente podemos usar la caja de texto ‘Wizards:’ para encontrar más facilmente lo que estemos buscando.

Indicamos dónde queremos dejar el fichero y le ponemos extensión ‘.xml’

Y tras eso seleccionamos qué namespaces vamos a querer ponerle al xml al crear el fichero. Generalmente usaremos ‘bean’

Como no tenemos nada más que añadir pulsamos ‘Finish’

• Y tambien podemos utilizar el plato fuerte, que es ver qué dependencias hay entre beans. Para ello tenemos que abrir una vista nueva incluida en el plugin tal y como se muestra en la imagen:

Se nos abrirá una pestaña en la barra de vistas inferior y se nos mostrará de manera esquemática el contenido de los xml que el proyecto tenga definidos como xml con beans declarados.

Si no apareciesen todos los ficheros con definiciones de beans que tenemos, o quisiesemos cambiarlos, podemos hacerlo fácilmente haciendo click con el botón derecho sobre el proyecto, y tras eso navegar hasta ‘Properties > Spring > Beans support’. Si quisiesemos ver las dependencias de manera gráfica, sólo hay que seleccionar la siguiente opción:

Tras eso nos aparecerá un gráfico de dependencias entre beans:

Como veis el uso del plugin es muy sencillo y permite, de un vistazo, poder saber qué dependencias hay entre beans, lo cual ayuda a simple vista a ver cómo está organizado en módulos el proyecto siempre que estemos utilizando Spring para desarrollarlo.

5. Spring WebFlow

El plugin no se queda en lo visto hasta ahora sino que además trae soporte para Spring Webflow. Para aprovecharnos de sus ventajas podemos crear ficheros de definición de flujos desde el asistente de creación de ficheros de un modo similar al explicado previamente. Hacemos click con el boton derecho del raton sobre el proyecto, y seleccionamos ‘New > Other …’

Igualmente indicamos dónde queremos dejar el xml

Y, si lo deseamos, podemos ‘enlazarlo’ con algun fichero de definición de beans que tuvieramos declarado anteriormente

Como ya mostramos previamente, cuando te creas un xml con definciones de bean el plugin te permitia ver qué relaciones de dependencia habia entre ellos. Pero si te creas un xml donde definir el flujo puedes ir un paso más y diseñarlo gráficamente:

En una primera instancia el flujo aparece vacio, mostrando únicamente el inicio.

Pero como se puede ver en esta imagen obtenida en la página web del plugin, la cosa puede complicarse hasta definir el flujo completo:

6. Conclusiones

Este plugin es un buen complemento para el desarrollo de aplicaciones que utilicen Spring desde Eclipse, ya que gracias a él es muy sencillo crear ficheros xml con distintos namespaces, ver qué dependencias hay entre beans y, en el caso de estar usando Spring Webflow, usar su asistente gráfico para crear el flujo de la aplicación.

En el dia a dia de desarrollo de aplicaciones de Spring con este plugin te das cuenta que es una herramienta útil y que, aunque no sea a diario, de vez en cuando es conveniente visualizar las gráficas de dependencias ya que nos ayudan a pensar, y a ver más fácilmente, si necesitamos todas las dependencias que inyectamos o no o cómo poder plantear una refactorización de código.

Espero que os sea de utilidad.