viernes, 16 de octubre de 2009

Site para el proyecto con Maven

Una buena práctica a la hora de publicar nuestros proyectos es, sin duda, crear un site para el proyecto en el que podamos añadir toda la información sobre el proyecto, desarrolladores, código fuente (en caso de desear compartirlo), informes sobre test, "issue tracking" y un sin fin de cosas. Es lógico que crear un site con toda está información desde cero es muy costoso, por tanto voy a proponer un sistema automático.

Para llevar a cabo esta automatización podemos usar el plugin de maven "Maven Site Plugin", el cuál generará el site automáticamente con toda la información que definamos en su configuración. Lo primero que debemos hacer es añadir el plugin en nuestro fichero pom.xml:

<project>
...
<build>
<!--Para usar las metas del plugin-->
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-site-plugin</artifactId>
<version>2.0.1</version>
</plugin>
...
</plugins>
</build>
...
</project>


Si queremos definir el plugin en el pom padre para que sea usado por todos los proyectos hijos podemos usar esto:

<project>
...
<build>
<!-- Para definir el plugin en el POM Padre-->
<pluginManagement>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-site-plugin</artifactId>
<version>2.0.1</version>
</plugin>
...
</plugins>
</pluginManagement>
...
</build>
...
</project>


Una vez que tenemos esto podemos ejecutar el comando mvn site para crear nuestro site, por defecto lo creara en la carpeta {basedir/target/site}. Obviamente el site generado tendrá la configuración por defecto y creará el contenido por defecto, estando la mayoría de la información sin rellenar. Algunos apartados puedes tener datos, como las dependencias o la información del proyecto y los desarrolladores, que serán extraídas del pom.


Configurar el site.
Para configurar el site a nuestro gusto e ir añadiendo la información que deseemos. En la carpeta src debemos crear la siguiente estructura:

+- src/
+- site/
+- apt/
| +- index.apt (versión por defecto)
|
+- site.xml (descriptor de la versión por defecto)


Para cambiar el ábol de navegación debemos configurar nuestro descriptor del site (site.xml), podemos ver como se crea un descriptor del fichero en la página oficial del plugin.


Configurar los informes
Podemos añadir los informes que generamos con otros plugins de maven. Hay muchos informes estándar disponibles que obtienen información del POM. Actualmente los que se proveen por defecto son los siguientes:
  • Informe de dependencias
  • Listas de correo
  • Integración Continua
  • Repositorio de código fuente
  • Seguimiento de errores (Issue Tracking)
  • Equipo del proyecto
  • Licencia.
Para añadirlos tan sólo debemos configuralos en la sección del POM y añadir las entradas correspondientes en el fichero site.xml, si esté ha sido modificado, ya que en el fichero por defecto se incluyen dichas secciones.

<project>
...
<reporting>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-project-info-reports-plugin</artifactId>
<version>2.0.1</version>
</plugin>
</plugins>
</reporting>
...
</project>



Internacionalización.
La internacionalización de nuestro site es muy sencilla, tan sólo debemos configurar el plugin para que admita varios locales, añadiendo en la configuración del plugin:

<project>
...
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-site-plugin</artifactId>
<version>2.0.1</version>
<configuration>
<locales>en,es</locales>
</configuration>
</plugin>
</plugins>
</build>
...
</project>


Y luego crear una carpeta para el contenido para cada idioma, el contenido del idioma por defecto irá en la carpeta raíz y crearemos una carpeta para cada idioma extra. Asimismo crearemos un descriptor del site en cada idioma, sería algo así:


+- src/
+- site/
+- apt/
| +- index.apt (versión por defecto)
|
+- es/
| +- apt/
| +- index.apt (versión en español)
|
+- site.xml (descriptor de la versión por defecto)
+- site_es.xml (descriptor de la versión española)



Ejecución y despliegue del Site.
Una vez que tenemos nuestro site, podemos ejecutarlo usando nuestra máquina como servidor con el comando mvn site:run y podemos acceder a él en el puerto 8080 del localhost (http://localhost:8080/). Si disponemos de un dominio y almacenamiento para nuestro site podemos publicarlo automáticamente, para ello debemos añadir en nuestro POM la la información de la URL a la que subiremos el site, en la configuración del distributionManagement:

<project>
...
<distributionManagement>
<site>
<id>www.yourcompany.com</id>
<url>scp://www.yourcompany.com/www/docs/project/</url>
</site>
</distributionManagement>
...
</project>


y luego ejecutar el deploy, para ello tenemos dos opciones:
  • mvn site:deploy : Este comando sólo despliega el site, por tanto el sitio debe haberse generado antes.
  • mvn site-deploy : Si queremos ejecutar todo el proceso desde generarlo hasta su publicación debemos ejecutar la fase site-deploy del ciclo de vida.

Os dejo un proyecto de prueba vacío en el que se aplica todo esto, para generar un site.





Como vemos, con esta herramienta podemos ahorrar mucho tiempo y generar un site con toda la información del proyecto, en otra ocasión continuaremos con más buenas prácticas.

Saludos.

miércoles, 14 de octubre de 2009

Preview de Bonita Studio 5.0

BonitaSoft ha puesto en circulación la preview de BonitaStudio 5.0, la nueva versión de su herramienta BPM (Bussines Process Management), por ahora solo está disponible como preview privada, y solo pueden acceder a ellas los usuarios registrados en el nuevo site de BonitaSoft antes del 10 de Octubre de 2009.

Por la información expuesta en el site podemos decir que han rediseñado la interfaz y la funcionalidad, cosa que se agradece bastante ya que la versión 4.0 me desencanto un poco.

Particularmente he trabajado con la versión 3 y 4 de Bonita y entre ellas hubo una gran diferencia. La versión 4 de Bonita es relativamente nueva y quiso cambiar completamente el esquema de la antigua Bonita, y esta nueva versión 5.0 viene a cubrir todos los huecos que la versión 4 dejo descubiertos, como la Interfaz gráfica y la API que era bastante limitada si se compara con la de la versión 3.

Yo ya le he descargado pero desafortunadamente no he tenido tiempo de probarla, en cuanto la pruebe comentaré mis primeras impresiones. Realmente espero que con está nueva versión se solvente algunos de esos pequeños problemas ya que estamos ante una de las mejores soluciones BPM del momento.

jueves, 1 de octubre de 2009

Acceder a servicio SOAP tras un proxy con CXF

Si queremos acceder, con CXF, a un servicio SOAP a través de un Proxy puede suceder que falle la llamada, ya que el resultado que nos devuelve es "troceado", y por tanto al recibir el mensaje de retorno, este no cumple con el formato SOAP.

Nos mostrará un error al acceder a la URL en la que se encuentra el servicio, indicándonos el mensaje "Método de la petición y protocolo no soportados". En el caso de que el proxy sea Squid nos mostrará también el siguiente mensaje "Squid no admite todos los métodos para todos los protocolos de acceso. Por ejemplo, no se puede hacer un POST a un servidor Gopher".

El stackTrace provocado por el error es algo similar a similar a este:


Para solucionar este problemas debemos configurar el CXF para desactivar el "chunking" (troceado), para ello crearemos/modificaremos el fichero de configuración de CXF (por defecto cxf.xml), consistente en un conjunto de beans de Spring, en el que añadiremos o descomentaremos, si ya existe el fichero, lo siguiente:

Podemos ver como configurar el CXF en la sección de configuración de la página oficial de Apache.

sábado, 29 de agosto de 2009

Ocultar pestañas en TabNavigator

Hoy veremos como se pueden ocultar las pestañas en un TabNavigator de Flex 3. Es un problema que parece trivial (en otros entornos realmente lo es), pero en Flex dado el manejo interno que hace Flex del TabNavigator no es tan directo, o por lo menos la forma de añadir pestañas en un mxml puede llevar a un uso incorrecto.

Cuando tenemos un TabNavigator, para añadir una pestaña tan sólo debemos añadir como hijo un contenedor, es decir cualquier clase que herede de la clase mx.Container (Box, Container, viewStack, etc...). Veamos un ejemplo:
Una vez que tenemos el TabNavigator creado, podemos decidir ocultar ciertas pestañas en determinadas circunstancias, o bien usando estados (mx:States) o con código actionScript. Para tratar de ocultar una pestaña la tendencia natural es usar el atributo visible y el includeInLayout (para no dejar huecos entre las pestañas) sobre los hijos que hemos añadido en el TabNavigator, con lo que obtendremos un resultado erróneo, ya que se mostrará el TabNavigator con la pestaña vacía en su interior.

A grosso modo, cuando nosotros añadimos un hijo en el TabNavigator internamente crea una pestaña (tab), en la que incluye el botón con el que se representa la pestaña y añade el contenido que nosotros hemos especificado. Por tanto, si queremos hacer que la pestaña desaparezca completamente debemos acceder al tab y establecer las dos propiedades mencionadas antes: visible e includeInLayout a valor false. Para acceder al tab debemos hacer uso de la función getTabAt del TabNavigator, con la que obtendremos la pestaña (un objeto de tipo mx.Button). Usando el ejemplo anterior, el código para ocultar la "pestaña 2, " resultante sería algo así:

 ...
var pestana:Button =
tabNavigator.getTabAt(1);
pestana.visible = false;
pestana.includeInLayout= false;
...

Cómo vemos de esta forma simple podemos jugar con las pestañas para ocultarlas y visualizarlas, y no sólo eso, sino que podemos acceder a las pestañas (tabs), para cambiar cualquiera de sus propiedades.

lunes, 17 de agosto de 2009

Aplicaciones modulares en Flex

Hola, despues de un pequeño descanso ya hemos vuelto. Hoy quería hablar de un tema que tenía en el tintero desde hace un tiempo. las aplicaciones modulares en Flex.

La primera cuestión que nos viene a la cabeza es ¿Por qué una aplicación modular?, por que hemos de complicar el desarrollo para desarrollar modulos y tener que añadir cierta lógica extra para manejarlos. En efecto, el desarroollo modular supone cierto coste en tiempo de desarrollo y de ejecución de la aplicación, por tanto no todas las aplicaciones son susceptibles de desarrollarse de forma modular. En mi opinión es una cuestión de tamaño y/o complejidad, para desarrollar una pequeña aplicación muy simple quizás no sea recomendable, dado la carga extra que supone. La modularidad empieza a mostrar sus ventajas conforme el proyecto crece y se complica, pudiendo observar grandes beneficios:
  • Reducción del tiempo de compilación --> Dado que trabajamos con módulos, sólo recompilaremos los módulos en los que hay acambios.
  • Reducción del tamaño de los archivos compilados (SWF y SWC).
  • Reutilización --> Podemos reutilizar dicho módulo en otras aplicaciones.
  • Simplifica la adición de nuevas funcionalidades mediante la adición de nuevos módulos.
  • Carga/descarga de módulos dinámicamente--> Liberación de recursos.
  • Desarrollo entre distintos grupos de trabajo.
La realización de programas modulares en Flex podríamos englobarla básicamente en 4 categorías:
  • Uso de Módulos.
  • Uso de Librerías.
  • Uso de RSL (Runtime Shared Libraries).
  • Uso de librerías, RSL y módulos de forma conjunta.
Modulos
Los módulos son archivos SWF que pueden ser cargados dinamicamente y que no pueden ejecutarse independientemente, sino que deben ejecutarse dentro de una o varias aplicaciones. Un módulo puede interactuar con la aplicación padre o con otros módulos.

Podemos definir un módulo usando la clase Module.

Librerías
Como en cualquier otro lenguaje, una librería es un conjunto de funcionalidades y/o recursos que se encapsulan, en este caso se encapsulan en un fichero SWC.

RSL (Resource Shared Library)
Como su nombre indica es la una librería de recursos compartidos. La importancia de este tipo de librerías es que dicha librería se carga una sola vez en el arranque de la aplicación (se puede ver la barra de carga al principio), de forma que desde ese momento podemos utilizar todos los recursos de la librería sin necesidad de cargar la librería. Como es lógico este proceso puede ralentizar el proceso de startup de la aplicación, así hay que decidir con cuidado que librerías se cargarán como RSL (basándonos en la utilización de la librería).
Otro punto importante del uso de RSL, es que usando lo adecuadamente podemos reducir el tamaño de nuestros módulos/aplicaciones, ya que la librería se compilara en un fichero aparte que será reutilizado, y no se incluirá el código especifico que se usa de la librería en cada archivo compilado SWF.

Desde mi experiencia, recomiendo encarecidamente el uso de aplicaciones modulares para aplicaciones de cierta envergadura, ya de esta manera se puede disfrutar de un conjunto de ventajas muy interesantes a un coste relativamente pequeños, ya que sólo requiere el coste inicial de la gestión de módulos y una vez que se tenga implementada dicha gestión se pueden añadir funcionalidades facilmente.