Se trata de MiniJoe, un interprete JavaScript, y org.json.me, una librería JSON en J2ME.

Con MiniJoe puedes ejecutar JavaScript en el móvil. Aunque tiene algunas limitaciones y no es ni de lejos tan potente como Rhino, por ejemplo, hace su trabajo con un API tan restrictivo como CLDC 1.1.

El problema es que la documentación es escasa y solo estudiando el código consigues hacerte una idea de como se utiliza.

A continuación, incluyo algunos fragmentos de código Java que te pueden ser útiles si te ves en la circunstancia de tener que utilizar esta librería:

// Mi propio objeto JSON en Java visible desde JS
public class JSON extends JsObject
{
	// ID de la función JS parse implementada en Java
	static final int ID_PARSE = 101;

	// ID de la función JS stringify implementada en Java
	static final int ID_STRINGIFY = 102;

	public JSON()
	{
		super(new JsObject(OBJECT_PROTOTYPE));

		// Añado la función parse que recibe un parámetro
		addNative("parse", ID_PARSE, 1);

		// Añado la función stringify que recibe un parámetro
		addNative("stringify", ID_STRINGIFY, 1);
	}

	// Implemementación de los métodos JSON nativos en Java
	public void evalNative(int id, JsArray stack, int sp, int parCount)
	{
		switch(id)
		{
			// Los parámetros se obtienen de la pila
			// sp + 2 = primer parámetro, sp + 3 = segundo, ...
	    		case ID_PARSE:
	    			stack.setObject(sp, parse(stack.getString(sp + 2)));
		    		break;

		    	case ID_STRINGIFY:
		    		stack.setObject(sp, stringfy((JsObject)stack.getObject(sp + 2)));
	    			break;

		    	default:
		    		super.evalNative(id, stack, sp, parCount);
		}
	}	

	// De String a JsObject
	private JsObject parse(String str)
	{
		...
	}

	// De JsObject a String
	public static String stringfy(JsObject obj)
	{
		...
	}
}

// Esta clase proveerá funciones y variables globales
// En concreto una función trace y la variable global JSON
public class MyEnvironment extends Eval
{
	// ID de la función JS trace implementada en Java
	static final int ID_TRACE = 101;

	public MyEnvironment()
	{
		super();

		// Añado la función trace que recibe un parámetro
		addVar("trace", new JsFunction(ID_TRACE, 1));

		// Añado la variable global JSON
		// Los objetos deben ser subclases de JsObject
		addVar("JSON", new JSON());
	}

	// Implemementación de funciones nativas en Java
	public void evalNative(int id, JsArray stack, int sp, int parCount)
	{
		 switch(id)
	    	{
	    		case ID_TRACE:
	    			trace(stack.getString(sp + 2));
		    		break;

			default:
	    			super.evalNative(id, stack, sp, parCount);
	    }
	}

	// Implementación de trace en Java
	private void trace(String text)
	{
		System.out.println("Traza: " + text);
	}
}

// Punto de entrada
	public static void main(String args[])
	{
		// Obtener el script
		String script = ...

		// Ejecutarlo en un entorno que contiene la función trace y el objeto JSON
		MyEnviroment env = new MyEnviroment();
		MyEnvironment.eval(script, env);

	}

La otra librería, org.json.me es mas sencilla y dispone de mas documentación. Aún así, el siguiente fragmento de código te puede ser útil para empezar:

// PARSE

// Cadena JSON
String str = ...

// Convertir a JSON (parse)
JSONObject json = new JSONObject(str);

// Obtener campos de JSON
System.out.println(json.getString("campo1"));
System.out.println(json.getBoolean("campo2"));

// STRINGIFY

// Cambiar el vlor de algunos campos
json.put("campo1", "Prueba");

// Convertir a cadena
System.out.println(json.toString());

• Java EE 6 Specification.
• Java EE Web Profile Specification.
• Java EE 6 Managed Beans Specification.

Puedes encontrar información al respecto en numerosos blogs, pero probablemente el mejor sitio para empezar es el artículo de Ed Ort en SDN.

Por otro lado, como era de esperar, la primera implementación completa ha venido de la mano de SUN con GlassFish v3^[1] que llega acompañado de NetBeans 6.8, con lo que ya existe un ecosistema completo J2EE 6.

Una de las críticas que se hacían a GlassFish era su carácter monolítico respecto a, por ejemplo, JBoss pero parece que con la infraestructura OSGi y las nuevas características de Java EE 6 en este sentido, ya no es un argumento válido.

Hasta el momento me he mantenido utilizando JBoss 4.x y Eclipse esperando a que JBoss 5.x alcance la madurez, pero teniendo en cuenta lo anterior y lo que he sufrido buceando en los foros de JBoss para encontrar información y documentación válida puede que sea el momento de pasarse a GlassFish y quien sabe si también a NetBeans.

1. http://blogs.sun.com/kevinschmidt/entry/glassfish_enterprise_server_v3_the

Ante la inclusión en el Anteproyecto de Ley de Economía sostenible de modificaciones legislativas que afectan al libre ejercicio de las libertades de expresión, información y el derecho de acceso a la cultura a través de Internet, los periodistas, bloggers, usuarios, profesionales y creadores de Internet manifestamos nuestra firme oposición al proyecto, y declaramos que:

1. Los derechos de autor no pueden situarse por encima de los derechos fundamentales de los ciudadanos, como el derecho a la privacidad, a la seguridad, a la presunción de inocencia, a la tutela judicial efectiva y a la libertad de expresión.
2. La suspensión de derechos fundamentales es y debe seguir siendo competencia exclusiva del poder judicial. Ni un cierre sin sentencia. Este anteproyecto, en contra de lo establecido en el artículo 20.5 de la Constitución, pone en manos de un órgano no judicial -un organismo dependiente del ministerio de Cultura-, la potestad de impedir a los ciudadanos españoles el acceso a cualquier página web.
3. La nueva legislación creará inseguridad jurídica en todo el sector tecnológico español, perjudicando uno de los pocos campos de desarrollo y futuro de nuestra economía, entorpeciendo la creación de empresas, introduciendo trabas a la libre competencia y ralentizando su proyección internacional.
4. La nueva legislación propuesta amenaza a los nuevos creadores y entorpece la creación cultural. Con Internet y los sucesivos avances tecnológicos se ha democratizado extraordinariamente la creación y emisión de contenidos de todo tipo, que ya no provienen prevalentemente de las industrias culturales tradicionales, sino de multitud de fuentes diferentes.
5. Los autores, como todos los trabajadores, tienen derecho a vivir de su trabajo con nuevas ideas creativas, modelos de negocio y actividades asociadas a sus creaciones. Intentar sostener con cambios legislativos a una industria obsoleta que no sabe adaptarse a este nuevo entorno no es ni justo ni realista. Si su modelo de negocio se basaba en el control de las copias de las obras y en Internet no es posible sin vulnerar derechos fundamentales, deberían buscar otro modelo.
6. Consideramos que las industrias culturales necesitan para sobrevivir alternativas modernas, eficaces, creíbles y asequibles y que se adecuen a los nuevos usos sociales, en lugar de limitaciones tan desproporcionadas como ineficaces para el fin que dicen perseguir.
7. Internet debe funcionar de forma libre y sin interferencias políticas auspiciadas por sectores que pretenden perpetuar obsoletos modelos de negocio e imposibilitar que el saber humano siga siendo libre.
8. Exigimos que el Gobierno garantice por ley la neutralidad de la Red en España, ante cualquier presión que pueda producirse, como marco para el desarrollo de una economía sostenible y realista de cara al futuro.
9. Proponemos una verdadera reforma del derecho de propiedad intelectual orientada a su fin: devolver a la sociedad el conocimiento, promover el dominio público y limitar los abusos de las entidades gestoras.
10. En democracia las leyes y sus modificaciones deben aprobarse tras el oportuno debate público y habiendo consultado previamente a todas las partes implicadas. No es de recibo que se realicen cambios legislativos que afectan a derechos fundamentales en una ley no orgánica y que versa sobre otra materia.

RTMP es un protocolo de comunicaciones propietario de Adobe Systems  para la transmisión de audio, vídeo y datos entre el Flash Player y el servidor. No solo permite crear streams de audio/vídeo, sino que también permite transmitir en tiempo real y en ambas direcciones otros tipos de datos con numerosas aplicaciones prácticas (Remote Shared Objects, etc.).

Tras liberar el código de Flex y Blaze DS, y la especificación AMF, Adobe da un paso mas en la estrategia de abrir sus productos y tecnologías y libera esta pieza clave del ecosistema de Flash.

Se trata de una inmejorable noticia para los que, en su día, apostamos por utilizar Flash en nuestros desarrollos RIA y nos ofrece un importante respaldo frente a los recelos que suscita utilizar una tecnología propietaria.

La noticia tiene numerosas implicaciones, especialmente en el ámbito de las aplicaciones multimedia, de juegos y para dispositivos móviles.

Hasta la fecha, una alternativa razonable para la transmisión de audio y vídeo era RTSP (Real Time Streaming Protocol) ya que la especificación de este protocolo es pública. Este hecho ha favorecido que haya sido adoptado por numerosos fabricantes y productos, entre los que destaca Apple con iTunes y QuickTime.

Basadas en RTSP y el formato ISMA MPEG-4, disponemos de varias herramientas open source que, combinadas o por separado, nos permiten crear aplicaciones de distribución de contenidos multimedia. Entre ellas encontramos kits open source para codificar, transmitir y reproducir audio y vídeo, como MPEG4IP, FFMPEG o VideoLAN, o servidores de streaming como el Darwin de Apple.

Sin embargo, Flash no soporta el protocolo RTSP lo que, en principio, no permite crear aplicaciones que combinen clientes Flash con servidores RTSP. Es cierto que es posible desarrollar soluciones híbridas utilizando Flash y un cliente RTSP como QuickTime o VLC, pero las posibilidades de integración son limitadas y el resultado suele ser pobre.

Por otra parte, parece poco lógico utilizar un componente extra para reproducir audio y vídeo desde una aplicación Flash cuando, precisamente, este es uno de los puntos fuertes del Flash Player. Hay que tener en cuenta que desde la versión 9, Flash Player es capaz de reproducir vídeo en formato H.264 (MPEG-4) además de los formatos previos H.263 (Sorenson Spark) y VP6 (On2). Todo ello con poco más de 1MB, una implantación del 95% y con versiones para Windows, Mac o Linux.

Teniendo en cuenta lo anterior, hoy por hoy, si tu plataforma en el cliente es Flash, lo deseable es utilizar RTMP. El problema es que el coste de las herramientas comerciales para la codificación y retransmisión de audio/vídeo, como el FMS o el FME de Adobe, está fuera del alcance de la mayoría de los presupuestos.

Al abrir la especificación de RTMP, Adobe facilita que surjan nuevas herramientas open source basadas en este protocolo lo que a su vez nos permitirá crear aplicaciones basadas 100% en Flash con un coste final asequible.

Ciertamente, ya existían algunas alternativas open source  como Mammoth y, sobre todo, el excelente Red5, sin embargo están basados en ingeniería inversa del protocolo, lo que supone que no se benefician de todas sus prestaciones, especialmente en la retransmisión de H.264, y plantea algunas dudas sobre su legalidad.

Con la publicación de la especificación y a falta de leer "letra pequeña" es de esperar que los productos open source que ya existían mejoren sustancialmente y que veamos nacer muchos otros.

¡Felicidades Adobe!

Como ya sabrás, en el mercado existen equipos hardware denominados KM switch (para teclado y ratón) o KVM switch (para teclado, monitor y ratón) que te permiten compartir teclado, monitor y ratón entre dos o mas equipos. Sin embargo, estos aparatos necesitan cableado adicional y pueden llegar a ser bastante caros. En este artículo te presento algunas alternativas basadas en software para realizar esta labor.

Los KM o KVM software switches son programas que utilizan la red de área local para compartir teclado, ratón y monitor por lo que, además de reducir el cableado, se reduce el coste que en muchos casos puede ser nulo. Además, los switches por software ofrecen mas funcionalidades que sus homólogos hardware como el clipboard compartido o la posibilidad de mover/copiar archivos entre los equipos, entre otras.

Categorías

Atendiendo a la función principal, podemos clasificar este tipo de software en tres categorías:

Para compartir el teclado y el ratón (KM)

Cada equipo tiene su propio monitor pero solo se utiliza un conjunto teclado-ratón conectado a uno de los equipos.

Cuando el puntero del ratón alcanza el borde del monitor de un equipo, el teclado y el ratón pasan a gobernar el equipo anexo. También se puede utilizar una combinación de teclas para alternar el control entre los equipos disponibles.

Normalmente disponen de la posibilidad de definir la posición física de los equipos para indicar cual es el ordenador que está a izquierda y derecha o incluso arriba y abajo.

Para compartir teclado, monitor y ratón (KVM o control remoto)

Solo un equipo tiene monitor, teclado y ratón. Utilizamos la pantalla de éste para gobernar el resto.

En esta categoría estaría el terminal remoto de Windows o el conocido VNC.

Para extender el escritorio utilizando la pantalla de otro ordenador

Estamos acostumbrados a ver equipos con dos monitores conectados a la tarjeta gráfica de un único ordenador, lo cual nos permite extender el escritorio de Windows a ambos. Sin embargo, en ocasiones deseamos hacer ésto mismo cuando disponemos de varios ordenadores cada uno con su propio monitor.

Si disponemos de una tarjeta gráfica con dos salidas podremos conectar un segundo monitor desconectándolo de su ordenador original, pero ¿que ocurre si queremos un tercer monitor o si el monitor que queremos reutilizar es el de nuestro portátil?.

El software de esta tercera categoría nos permite extender el escritorio de Windows a los monitores de otros equipos, incluyendo portátiles, sin tocar el cableado. El ordenador maestro se apropia de los monitores del resto de los equipos utilizándolos como si estuvieran conectados directamente a él.

Sofware evaluado

En mi caso buscaba software de la primera categoría (KM), aunque no me he podido resistir a hacer algunas pruebas con la segunda y la tercera. Lo cierto es que algunos de los programas que he encontrado abarcan incluso las tres categorías.

Synergy

Es el software KM más veterano.

Es open source y su característica más destacable es que es multiplataforma, por lo que podremos compartir el teclado y el ratón entre equipos Windows, Mac o Linux.

Es muy estable y hace lo que promete.

Como inconvenientes he encontrado que:

• Tras apagar un equipo hay que volver a conectarlo manualmente (no detecta la presencia automáticamente).
• No permite compartir ficheros mediante el clipboard.
• La configuración es difícil para un profano.

InputDirector

Se trata de software gratuito (freeware) y es el que he decidido utilizar.

No tiene los problemas de Synergy, por ejemplo, permite el intercambio de ficheros mediante el clipboard siempre que las carpetas estén compartidas.

Sin embargo, solo corre en Windows (2000, XP o Vista).

MaxiVista Professional

Aunque es comercial, el precio es aceptable y las prestaciones son espectaculares, ya que engloba las tres categorías.

No lo he seleccionado por que no soporta el interfaz Aero de Windows Vista y porque, además, supera mis necesidades inmediatas.

Te lo recomiendo si tienes un ordenador de sobremesa y un portátil.

Otros no evaluados

Multiplicity

KM. Comercial.

KaVoom!

Varios productos: KM, KVM y ExtraMon. Comercial.

Win2VNC

KM. Principal Windows y secundarios Windows o Linux. Basado en VNC. Freeware.

Teleport

Solo Mac. Freeware.

KMremoteControl

Solo Mac. Freeware.

ScreenRecycler

Similar a MaxiVista. Prinicpal Mac y secundarios Mac o Windows. Comercial.

Un amigo me ha advertido de esta noticia de Reuters y no podía dejar pasar la ocasión de escribir unas líneas al respecto.

Parece que Philips ha desarrollado un prototipo de "píldora inteligente" con tecnología inalámbrica destinada al tratamiento de enfermedades del aparato digestivo.

Dispone de sensores de acidez y temperatura, y de un depósito para dispensar las medicinas donde y cuando se necesitan.

Ya conocíamos las píldoras de software… ¡Demos la bienvenida a las píldoras de hardware!.

El mensaje de error en estos casos suele ser algo como Error #1065: No se ha definido la variable MyClass.

Se trata de un problema de classloading y se debe a que el compilador de Flex no incluye en el archivo SWF las clases que no se referencian explícitamente en el código.

Por ejemplo, el siguiente código fallará a menos que la clase MyClass se utilice en alguna otra parte:

import com.softwarepills.MyClass;

var clazz:Class = getDefinitionByName("com.softwarepills.MyClass") as Class;
var instance:Object = new clazz();					

A pesar de utilizar import, el SWF resultante no incluye la clase MyClass.

Para que el compilador incluya la clase es necesario utilizarla como en:

import com.softwarepills.MyClass;

var clazz:Class = getDefinitionByName("com.softwarepills.MyClass") as Class;
var instance:MyClass = new clazz() as MyClass;					

Si, esto si funciona, pero si usamos reflection es porque, precisamente, no queremos incluir una referencia explícita a la clase.

Buscando en la Red he encontrado varias soluciones^[1]. Una consiste en utilizar en una variable "dummy" en un punto arbitrario del código, por ejemplo:

import com.softwarepills.MyClass;

var dummy:MyClass = new MyClass();					

Este sistema no me gusta porque puede llevar a confusión y, además, es demasiado código para tan poca cosa.

El segundo método que se menciona consiste en crear un librería SWF con todas las clases que necesitamos y compilar la aplicación con ella, pero esto me parece demasiado aparatoso y propenso a errores.

Investigando un poco más he encontrado la que me parece la solución "menos mala", que consiste en utilizar un bloque de código estático como en el siguiente ejemplo:

import com.softwarepills.MyClass;
import com.softwarepills.MyOtherClass;

{MyClass,MyOtherClass}

Esta es para mi la forma mas compacta y menos aparatosa; se trata de enumerar las clases dentro de un bloque estático en cualquier cualquier fichero .as o .mxml de la aplicación.

¿No sabias que existía un bloque estático de código? Yo tampoco. Lo encontré en un artículo de insideria.com, donde también puedes enterarte de otras formas de trabajar con código estático o de incialización.

1. Como en http://thillerson.wordpress.com/2007/03/01/runtime-class-instantiation-in-actionscript-30/

Sin embargo, después de varios meses aplicándolo descubres que tiene sus inconvenientes: Cairngorm requiere mucho código repetitivo y, en ocasiones, es demasiado "retorcido" en situaciones que no lo justifican. Entonces, te empiezas a preguntar si quizá existe una arquitectura mejor, que requiera menos código y que te permita concentrarte más en la aplicación y menos en los detalles de implementación.

En esta entrada indagaré en las alternativas que existen en éste momento y seleccionaré las mejores candidatas a suceder a Cairngorm.

Para empezar, voy a tratar de enumerar las debilidades de Cairngorm y cuales deberían ser, desde mi punto de vista, las características de su sucesor.

Las debilidades de Cairngorm

Cualquiera que utilice Cairngorm lo ha sufrido; hay que escribir un montón de código repetitivo: el evento, el comando, el BusisnessDelegate,… y ya sabemos que más código significa más trabajo para mantenerlo.

Se abusa de los singletons, lo que hace que la aplicación sea más monolítica y los componentes estén demasiado acoplados; por ejemplo, los comandos son difícilmente reutilizables. En Java hace ya tiempo que los abandonamos (ServiceLocator, ModelLocator, etc.) en favor de otras técnicas como el IoC.

Por otro lado, para hacer que los componentes de las vistas sean algo más reutilizables se aconseja no usar los singletons en los componentes internos y hacerlo solo en los componentes de nivel superior. Esto implica que debemos utilizar variables para propagar los datos desde las vistas de nivel superior a los componentes mas internos y eventos para el recorrido inverso. Esto implica que muchos componentes manejan datos que no utilizan, solo para pasárselos a un componente de nivel superior o inferior.

No hay una solución limpia para implementar las acciones de usuario que implican la ejecución de varias tareas asíncronas. Los comandos encadenados son un parche y no una verdadera solución para este caso de uso^[1].

Aunque Cairngorm pretende separar las responsabilidades y establecer la metodología y el modelo de programación, en muchos casos es ambiguo y los programadores tienen problemas para identificar cuando una variable es de estado o del modelo, cuando se puede actuar directamente sobre la vista o hay que utilizar un evento-comando, etc.

Otro aspecto que no me gusta, es que utiliza un sistema de despachado de eventos propio. No comprendo la necesidad de hacer esto cuando Flex dispone de una gestión de eventos muy completa y eficiente.

Finalmente, aunque es posible conseguir una aplicación modular con Cairngorm, la solución no es inmediata. En mi caso fue necesario modificar algunas de las clases del núcleo para conseguir algo parecido a una aplicación modular.

Los requisitos

El nuevo framework debe aportar soluciones a las debilidades de Cairngorm, empezando por abandonar el uso de singletons y facilitar el desacoplamiento de los componentes. Una buena alternativa es el uso de IoC que, como luego veremos, está empezando a ser muy común también en los frameworks de Flex.

Debe reducir y simplificar el código de modo que el programador no se pierda en los detalles de la implementación y pueda centrarse en la funcionalidad.

También sería deseable que facilite la construcción de aplicaciones modulares y que utilice al máximo las características propias de Flex. Después de todo Flex es, en sí, un framework de aplicación y lo que buscamos es una arquitectura y unas utilidades que nos faciliten la vida^[2].

Por último, debe facilitar los unit tests y el uso de mock objects y, por supuesto debe ser open source y, como para cualquier otro software, es deseable que disponga de buena documentación, de una comunidad de desarrolladores activa, que tenga gran implantación y perspectivas de continuidad.

Alternativas descartadas

Flex adquirió popularidad con el lanzamiento de la versión 2 en 2006. Por aquel entonces muchos decidimos utilizar Cairngorm porque prácticamente era el único framework de arquitectura disponible. Desde entonces, es sorprendente la cantidad de alternativas que han surgido.

Dado el número de candidatos, he descartado aquellos que, a primera vista, no cumplen los requisitos o que, estudiados más de cerca, no parecen aportar ventajas significativas respecto a Cairngorm.

La lista de candidatos rechazados es la siguiente:

ARP

Es uno de los mas veteranos, ya que se venía usando en aplicaciones Flash, y es genérico para AS2/AS3.

Servebox Foundry

Incluye ciertas prestaciones de alto nivel como browsing (navegación), globalización, búsquedas y control de acceso, para lo cual debes usar subclases de sus propios objetos aplicación, form, etc.

Es un conjunto de soluciones, incluyendo parte servidor, que utilizaba la empresa ServerBox en sus desarrollos y que han decidido convertir en un proyecto open source.

Flicc

Es un implementación IoC basada en MXML.

No resuelve nada en el resto de aspectos (MVC, comunicación con el servidor, etc).

Flest

Utiliza closures como comandos.

Conserva muchos de los puntos débiles de Cairngorm.

Parece que no hay actividad desde Agosto del 2007.

Flex IOC

Como Flicc, es solo una implementación del patrón IoC, pero con anotaciones y en menos de 100 líneas de código.

Lo conozco hace tiempo y creo que fue el primero en utilizar anotaciones (probablemente sea el origen de la idea).

Gaia

Está orientado a aplicaciones Flash (AS2/AS3).

Guasax

Se basa en una filosofía similar a Struts, donde los acciones se declaran en XML (los métodos de los Business Objects).

Dispone de interceptores para las llamadas y de una gestión de roles de usuarios.

Reduce el código, al eliminar el evento y el comando de Cairngorm, sustituyéndolo por llamadas con arrays y el XML de acciones, y moviendo el código del comando y el BusinessDelegate a los Business Objects.

El uso de XML y de arrays hace que el compilador no pueda ayudarnos en la detección de errores de tipo.

En resumen, sigue utilizando singletons pero reduce el código repetitivo.

La última actualización es de Septiembre de 2007.

Model-Glue: Flex

Creado a partir de una versión para ColdFusion.

Utiliza clases helper e invocación implícita para eliminar código repetitivo (los componentes lanzan eventos que recoge el contenedor).

Tiene escasa documentación y el proyecto parece estar detenido en una versión Alpha.

MVCS

No es un framework, es un diseño  o blueprint.

Parsley (SpiceFactory)

Incluye IoC basado en XML, MVC y prestaciones de localización (vía XML).

Tiene los componentes esenciales para ser una buena plataforma y, además, dispone de muy buena documentación, pero faltan herramientas básicas para el trabajo con RemoteObjects. Esto se debe a que la misma empresa distribuye  un componente servidor llamado Cinnamon Remoting que tiene sus propios mecanismos de acceso.

Puede que en el futuro sea una opción interesante.

Penne

Otra simplificación de Cairngorm (en este caso quizá una sobre-simplificación).

El autor tiene obsesión por la pasta y utiliza nombres del estilo "getPastaTypes" o "IPastaRemoteRequest". En fin…

Prana

Es una implementación IoC basada en Spring y XML. Creo que fue la primera y, probablemente, es la mas establecida y la más documentada.

Lo interesante es que tiene soporte para Cairngorm y PureMVC.

El uso de XML y contextos de aplicación puede ser aplicable para crear aplicaciones modulares.

PureMVC/Flex

Quizá sea el framework MVC para Flex más adoptado después de Cairngorm.

Esta muy bien documentada, pero se trata de una implementación neutral disponible para varios lenguajes, de modo que no utiliza a fondo las prestaciones de Flex en cuanto a gestión de eventos o bindings.

Utiliza algunos singletons como el ServiceLocator ya que no hace uso de IoC.

En http://www.techper.net/2008/10/05/4-things-to-hate-about-puremvc/ se describen algunos otros defectos.

La descarto, no sin muchas dudas, por que intuyo que la curva de aprendizaje es larga y que, además, no va a simplificar la programación. Al contrario, me temo que su adopción implicaría meternos en un mar de patrones que "formalmente" sería lo aconsejable, pero en la práctica puede ser excesivo.

Slide

La documentación es casi nula.

Smartypants IOC

De nuevo una implementación de IoC pero, a diferencia de la mayoría, está basada en la filosofía de Guice y no en Spring.

VEGAS

Se trata de un conglomerado de librerías para AS1/2/3. Entre ellas encontramos implementaciones de patrones MVC e IoC.

Los finalistas

Después de la primera criba, estos son mis dos finalistas: Mate y Swiz.

Por el camino he abandonado otras opciones que no descarto retomar si estos dos no están a la altura de mis expectativas. Sin embargo, los dos tienen aspectos interesantes y  novedosos que los hacen merecedores de un estudio en profundidad.

Mate

Mate es uno de los nuevos frameworks que últimamente ha adquirido una gran popularidad. Seguramente es el más adoptado después de Cairngorm y PureMVC.

Mate no impone un patrón, sino que ofrece una serie de herramientas que te permiten crear aplicaciones RIA con MVC de una forma no intrusiva, es decir, observando el código no encontrarás referencias al framework. Es el framework quien, desde "fuera", gestiona las clases de tu aplicación utilizando técnicas de IoC.

Para ello se utiliza un fichero MXML central, el EventMap, que incluye los tags que definen como se va a comportar tu aplicación. Por ejemplo, mediante el tag Injectors es posible inyectar valores en la vistas tras obtener del servidor los resultados de una petición.

Además, Mate es un proyecto muy activo y dispone de suficiente documentación.

El único aspecto negativo que puedo intuir en este momento es que los EventMaps pueden llegar a ser muy extensos y difíciles de interpretar en aplicaciones grandes, al estilo de lo que venía ocurriendo con Spring.

Estos son algunos enlaces que te pueden ser útiles para conocer un poco mejor este framework:

• La presentación en vídeo.
• Artículo de flashmagazine.com.
• Otra revisión.
• Un artículo que destaca sus puntos débiles.
• Un diagrama de su arquitectura. 

Swiz

Es probablemente el framework mas innovador y mas reciente, pero ya ha cautivado la atención de la comunidad de desarrolladores de Flex (y la mía también).

Se basa en un núcleo IoC que utiliza ficheros MXML llamados BeanLoaders para definir los componentes (al estilo Spring) y anotaciones para definir los puntos de inyección (por lo que no es necesario el uso de XML). Esto, de entrada, elimina la necesidad de singletons explícitos.

Cuando creamos una vista, el contendor de IoC detecta que se ha añadido un componente al stage y automáticamente inyecta las variables necesarias sin necesidad de código adicional; simplemente anotando la variable con Autowire.

Por si esto fuera poco, además, incluye una serie de utilidades que permiten trabajar con las llamadas asíncronas de una forma muy cómoda y poco aparatosa gracias a las clases DynamicCommand y DynamicResponder que se crean bajo demanda "en el aire". Incluso puedes encadenar varias llamadas asíncronas con la clase CommandChain.

También dispone de una anotación Mediate que permite asociar los eventos con las funciones que los atienden en el controlador, por medio de lo que el autor llama DynamicMediators. Esto elimina también el típico código que llama a una función al recibir el evento.

En la gestión de eventos no reinventa la rueda y utiliza la infraestructura de Flex, lo cual hace el framework aún menos intrusivo.

En esencia, en una aplicación Swiz solo intervienen las vistas , los eventos, el controlador y, si se quiere así, los Busisness Delagates. El resultado es sorprendente: desaparece todo el código repetitivo y se entiende a la perfección.

Tengo que decir que, por ahora, es la opción que más me atrae, sobre todo, por su simplicidad.

Sin embargo, también tengo algunas dudas: la documentación es escasa (pero es que… es tan sencillo!), me preocupa la continuidad del proyecto y su nivel de aceptación, y aún queda ver como se comporta en aplicaciones grandes y modulares. En resumen, la apuesta es arriesgada.

Otro aspecto no resuelto, por el momento, es el tema de los mock objects, pero seguro que hay alguna solución si se estudia detenidamente^[3]

Algunos enlaces relacionados son:

• La presentación en vídeo.
• El blog del autor.
• Un artículo de alguien tan impresionado como yo.

Otros recursos en Internet

• Un artículo similar.
• Otro artículo
• Vídeo de un charla en Adobe comparando frameworks.

Ahora toca estudiar en detalle los tres finalistas y hacer algunos ensayos con diferentes casos de uso para ver quién es el digno sucesor de Cairngorm.

Mientras tanto si tienes experiencia con alguno de ellos, te agradecería un comentario con tus impresiones.

1. Utilizando Universal Mind Cairngorm Extensions se solucionan parcialmente este y otros problemas de Cairngorm
2. Esta es una conversación interesante sobre la necesidad de usar un framework en Flex: http://flexblog.faratasystems.com/?p=280
3. En este artículo se describe una alternativa: http://soenkerohde.com/2008/10/conditional-compilation-to-mock-with-swiz/

Sin embargo, el proceso de aprendizaje ha sido largo y duro, entre otras cosas, porque Maven parece estar en un continuo estado de inestabilidad, plagado de detalles indocumentados, de versiones Beta, actualizaciones, etc. Tanto es así, que aún después de haber leído los dos libros gratuitos que hay en la Red^[2], la documentación y numerosos foros y artículos, todavía me quedan muchos puntos oscuros.

Hasta ahora Maven me ha sido muy útil en temas como en la automatización del proceso de construcción, almacenamiento de los artefactos de forma ordenada utilizando repositorios compartidos o la obtención de artefactos de terceros almacenados en repositorios en Internet y, sin embargo, me he encontrado muchos problemas en lo que se supone que es un punto fuerte de Maven: la gestión de dependencias.

Aquí comienza una serie de tres entradas en las que voy a tratar de explicar como funciona la gestión de dependencias en Maven pero, sobre todo, voy a profundizar en los aspectos que no están claros en la documentación (o que no lo estaban para mi) y que he aprendido, a las malas, con la experiencia.

En esta entrada hablaré sobre los aspectos básicos de la gestión de dependencias con Maven, la segunda tratará características avanzadas y la tercera y última estará dedicada a diseño y buenas prácticas^[3].

Versiones

Maven utiliza un esquema de versiones que consta de las siguientes partes:

<major version>.<minor version>.<incremental version>-<qualifier>

• Versión mayor:  normalmente un cambio de versión mayor denota incompatibilidad con las versiones anteriores.
• Versión menor: se incrementa cuando se incorporan nuevas funcionalidades, pero compatibles.
• "Bug fix" o versión incremental: se cambia cada vez que se lanza una nueva versión que repara algún error.
• "Qualifier" o "Build Number": se separa por un guión y marca hitos o "millestones" previos a la distribución del artefacto, por ejemplo, alpha, beta o  GA.

Aunque este es el esquema estándar de versionado, con frecuencia encontrarás que no siempre se utilizan todas las partes de una versión y que se recurre a versiones abreviadas como 1.2, 2.0-beta, etc.

Normalmente, para determinar si una versión es superior a otra se utiliza una comparación numérica, lo cual funcionará siempre que se respete el esquema anterior. Sin embargo es frecuente encontrar versiones con partes que incluyen números además de letras y entonces Maven realizará una comparación alfanumérica que puede no ser siempre correcta.  Esto es especialmente habitual en los calificadores. Por ejemplo 1.2.3-alpha-10 se considerará inferior a 1.2.3-alpha-2.

Las versiones se utilizan para etiquetar cada lanzamiento o "release" de un artefacto, son inmutables y corresponden a un conjunto de fuentes etiquetados a su vez en el control de versiones. Sin embargo, durante el desarrollo se generan artefactos temporales denominados "SNAPHOSTS" que no corresponden a un hito; simplemente se utilizan para hacer ensayos o para trabajar en equipo.

El versionado de los snapshots es parcialmente generado por Maven en base al momento de la construcción del artefacto.

El ejemplo muestra la versión de un snapshot; en este caso el snapshot corresponde a un artefacto temporal generado el día 11/2/2006 a las 13:11:14 durante el desarrollo para alcanzar la versión 1.0.1-1.

Este esquema de versionado se utiliza cuando interesa conservar varios snapshots y así poder volver a un estado anterior del desarrollo, pero también se puede configurar Maven para que solo se utilice una versión única de snapshot, en cuyo caso se sustituye el build number por el texto fijo SNAPSHOT, por ejemplo, 1.0.1-SNAPSHOT-1. Cuando Maven se configura de este modo cada snaphsot sustituye al anterior, es decir, solo se conserva una copia del snapshot correspondiente a la última construcción^[4]

Dependencias

Para especificar las dependencias en Maven se utiliza la sección dependency del POM:

<project>
	...
	<groupId>com.softwarepills</groupId>
  	<artifactId>sample</artifactId>
  	<version>1.0</version>
  	...
	<dependencies>
		<dependency>
			<groupId>log4j</groupId>
			<artifactId>log4j</artifactId>
			<version>1.2</version>
			<type>jar</type>
		</dependency>
		...
	</dependencies>
	...
</project>

Como veremos más adelante, no siempre es necesario enumerar aquí todas las dependencias, ya que nuestro POM puede adquirirlas por otros mecanismos.

Herencia

El primero de estos mecanismos es la herencia:

<project>
	...
	<parent>
		<groupId>com.softwarepills</groupId>
		<artifactId>sample</artifactId>
		<version>1.0</version>
	</parent>
	<artifactId>sample-app</artifactId>
	<version>1.0</version>
	...
</project>

En el ejemplo, al declarar un padre, nuestro POM adquiere las dependencias de éste (log4j). El concepto de herencia tiene el mismo significado que en POO: el hijo hereda las características del padre.

Por el momento a nosotros solo nos interesan las dependencias, pero es necesario aclarar que también se heredan otros atributos del POM padre por lo que no siempre la herencia es el mejor método para compartir y transmitir dependencias.

Para comprobar como queda el POM incluyendo las aportaciones de los padres podemos utilizar el comando:

mvn help:effective-pom

Dependencias transitivas

Las dependencias transitivas son aquellas que se establecen indirectamente, es decir, si el artefacto A depende de B y B depende de C, entonces se establece una dependencia transitiva entre A y C.

Gracias a esta característica introducida  por primera vez en Maven 2.0, podemos especificar solo las dependencias directas y dejar que Maven se encargue de recopilar el resto, o lo que es lo mismo, no tenemos que especificar todas y cada una de las dependencias transitivas en nuestro POM.

Utilizando las dependencias transitivas, Maven construye el árbol de dependencias que se utilizará más adelante con diferentes propósitos.

Para visualizar el árbol de dependencias podemos ejecutar el comando:

mvn dependency:tree

Composición

Como en POO, además de la herencia, en Maven existe otro mecanismo con el que transmitir y compartir atributos o funcionalidad: la composición.

Gracias a la transitividad de las dependencias  podemos agrupar un conjunto de versiones en un POM y hacer uso de ellas en diferentes artefactos. En el siguiente ejemplo se agrupan las dependencias relacionadas con el framework Spring:

<project>
	...
	<groupId>com.softwarepills</groupId>
  	<artifactId>spring-deps</artifactId>
	<version>${spring.version}</version>
	<packaging>pom</packaging>
  	...
	<dependencies>
		<dependency>
			<groupId>org.springframework</groupId>
			<artifactId>spring-core</artifactId>
			<version>${spring.version}</version>
		</dependency>
		<dependency>
			<groupId>org.springframework</groupId>
			<artifactId>spring-beans</artifactId>
			<version>${spring.version}</version>
		</dependency>
		...
	</dependencies>
	...
	<properties>
		<spring.version>2.0.5</spring.version>
	</properties>
	...
</project>

En este caso, además,utilizamos la variable spring.version para almacenar la versión. Esta técnica hace que nuestros POMs sean más legibles y fáciles de mantener.

Luego, en uno o mas artefactos propios podríamos hacer uso del conjunto de dependencias declarando una dependencia del POM de Spring, como en el siguiente ejemplo:

<project>
	...
	<groupId>com.softwarepills</groupId>
  	<artifactId>spring-project</artifactId>
  	<version>1.0</version>
  	...
	<dependencies>
		<dependency>
			<groupId>com.softwarepills</groupId>
			<artifactId>spring-deps</artifactId>
			<version>2.0.5</version>
			<type>pom</type>
		</dependency>
		...
	</dependencies>
	...
</project>

El principio "prefiere la composición a la herencia" que aconseja en el diseño POO, también rige aquí. La herencia es un mecanismo muy cómodo pero también muy rígido. Si abusas de ella te puedes encontrar problemas a la hora de incorporar modificaciones sobrevenidas.

Resolución de versiones

El objetivo de la gestión de dependencias es obtener el conjunto de artefactos o classpath que se utilizará en una determinada fase de la construcción del proyecto. Hasta ahora hemos hablado del árbol de dependencias, pero es evidente que no es lo que necesitamos… un árbol tiene ramas y una misma dependencia puede aparecer en más de una rama y, lo que es peor, puede aparecer con diferente versión.

Por ejemplo, en el gráfico adjunto se muestra un árbol de dependencias en el que el artefacto E aparece en dos ramas con diferentes versiones.

La resolución de versiones consiste en obtener un classpath sin artefactos duplicados a partir del árbol de versiones. El algoritmo que utiliza Maven para determinar la versión correcta se basa en la profundidad de la dependencia dentro del  árbol. Ante un conflicto, Maven siempre va a seleccionar la versión más cercana en el árbol. Así, en el ejemplo, Maven resolverá que la versión del artefacto E a incluir en el classpath será la 1.2 pues está en un nodo menos "profundo" que la versión 1.1.

En caso de que las diferentes versiones se encuentren a la misma profundidad, a falta de un criterio lógico,  Maven seleccionará una cualquiera de forma arbitraria.

Hasta ahora solo hemos hablado de versiones "blandas". Con ellas damos "pistas" a Maven para que seleccione la versión apropiada pero, para acotar la resolución de versiones de forma más estricta, podemos usar rangos:

Utilizando rangos en vez de versiones "blandas" limitamos las posibilidades a la hora de resolver las dependencias y, por tanto, puede llegar a darse el caso de que el classpath sea irresoluble.

Al utilizar rangos hayq ue tener cuenta que las versiones snapshot siempre se consideran inferiores a las releases, así que, por ejemplo, [1.2,) no incluye 1.2-SNAPSHOT.

Podemos comprobar como se resuelven las dependencias con el comando:

mvn dependency:resolve

Como veremos en el siguiente apartado, la resolución de versiones no es única. Durante el ciclo de vida de la construcción de un proyecto se generan diferentes árboles de dependencias que dan como resultado diferentes conjuntos de versiones para distintos contextos o "scopes".

Ámbitos de dependencia

El ámbito o "scope" de cada dependencia afecta a la construcción del proyecto en tres vertientes:

1. Las dependencias se resuelven por separado en cada fase pudiendo resultar diferentes classpaths en cada una de ellas.
2. Cada tarea individual, cada plugin, puede actuar de diferente forma según el scope.
3. Pueden afectar a la transitividad.

Los ámbitos disponibles en Maven son:

• compile (por defecto): las dependencias se incluyen en todos los classpath y se propagan a los proyectos dependientes.
• provided: se utiliza para indicar que la dependencia la provee el entorno de ejecución (o contenedor como JBoss) y, por tanto, no se incluye en las fases de empaquetado. Las dependencias de este tipo no son transitivas.
• runtime: se utiliza solo en ejecución, por tanto, se incluye en los classpath de ejecución y tests pero no en la compilación.
• test: solo se utiliza en las fases de compilación y ejecución de los tests.
• system: en concepto es similar a provided pero se debe indicar la ruta donde está el JAR. No se obtendrá de un repositorio y estará siempre disponible. Se utilizan para extras del JDK, JDBC, etc.
• import: importa las dependencias declaradas de la sección dependencyManagement de un POM en la misma sección de otro^[5].

El siguiente ejemplo, declara la dependencia de JUnit con scope provided:

<project>
	...
	<groupId>com.softwarepills</groupId>
  	<artifactId>sample</artifactId>
  	<version>1.0</version>
  	...
	<dependencies>
		<dependency>
			<groupId>junit</groupId>
			<artifactId>junit</artifactId>
			<version>4.0</version>
			<type>jar</type>
			<scope>test</scope>
		</dependency>
		...
	</dependencies>
	...
</project>

Además, para terminar de complicar el asunto, los ámbitos de dependencia se transmiten de forma transitiva según la siguiente tabla:

En la tabla, la dependencia entre A y B determina la fila, la dependencia entre B y C determina la columna, la intersección determina la dependencia entre A y C.

Como consejo para simplificar el diseño de tu POM, inicialmente, piensa solo en el concepto que subyace en cada sope: compile es una dependencia "normal" sin ninguna connotación especial,  provided es una dependencia que aporta el contenedor y, por tanto, no tenemos que distribuirla con nuestro artefacto, etc. Con esto, tienes un buen punto de partida que probablemente será suficiente.

Si es necesario, en una fase posterior, puedes refinarlo analizando las tres vertientes antes mencionadas. Por ejemplo, cuando declaramos que una dependencia es de tipo provided obtenemos que:

1. Se incluirá en todos los classpath (como si fuera compile).
2. Normalmente no se empaquetará (en un WAR, por ejemplo).
3. No será transitiva: si A depende de B y B depende de C como provided, A no depende de C a menos que C se declare como dependencia directa en A^[6].

En la próxima entrada trataré el resto de elementos que intervienen en la gestión de dependencias en Maven: la sección dependencyManagement, las exclusiones y la gestión de snapshots.

1. Al contrario que Apache Ant, que tiene un enfoque procedural.
2. En la última entrada incluiré reseñas bibliográficas y de otros recursos en Internet.
3. Todo lo que se refiere en esta serie de artículos está basado en la versión 2.1.0-M1. Como ya he dicho, Maven está en continua evolución y puede que tu versión no se comporte igual en ciertos aspectos.
4. En la próxima entrada explicaré en detalle la gestión de snaphots.
5. Lo explicaré en la segunda entrada de esta serie
6. La no transtividad de las dependencias provided, desde mi punto de vista no tiene mucho sentido. Es algo que se está debatiendo en este momento y que probablemente cambie en próximas versiones de Maven

Si quieres integrar esta herramienta en la construcción de un proyecto con Maven puedes utilizar el maven-apt-plugin de Tobago^[1]. Este plugin hace casi todo el trabajo pero, como veremos más adelante, es necesario realizar algunos ajustes para que el proyecto se construya de forma adecuada en la línea de comandos y en Eclipse con m2eclipse.

El siguiente fragmento de POM muestra la configuración  básica de este plugin:

<!-- Generación de clases a partir de las anotaciones -->
<plugin>
	<groupId>org.apache.myfaces.tobago</groupId>
	<artifactId>maven-apt-plugin</artifactId>
	<executions>
		<execution>
			<id>generate-java</id>
			<phase>generate-sources</phase>
			<goals>
				<goal>execute</goal>
			</goals>
			<configuration>
				<factory>com.softwarepills.apt.MyAnnotationProcessorFactory</factory>
				<includes>
					<include>com/softwarepills/myapp/*.java</include>
				</includes>
				<generated>src/main/apt_generated</generated>
				<force>true</force>
				<nocompile>true</nocompile>
			</configuration>
		</execution>
	</executions>
</plugin>

Con esta configuración conseguimos que las clases situadas en el paquete com.softwarepills.myapp sean procesadas por com.softwarepills.apt.MyAnnotationProcessorFactory y el resultado quede en el directorio src/main/apt_generated.

Los elementos que intervienen en esta configuración son:

• phase: el proceso de las anotaciones ocurre en la fase generate-sources, es decir, antes de la compilación.
• factory: clase encargada de procesar las anotaciones y de generar el código fuente derivado^[2].
• includes: filtro de las clases y paquetes que queremos procesar.
• generated: directorio donde deseamos que se escriba el código fuente generado.
• force: forzamos que las anotaciones se procesen cada vez que se ejecuta Maven sin comprobar si el código fuente original ha cambiado. Es algo más lento, pero evita problemas.
• nocompile: este plugin es capaz de compilar el código generado. Sin embargo, es preferible que no lo haga y dejárselo al plugin de compilación. Así todo el código fuente (el original y el generado) se trata de la misma forma.

Si desde la línea de comando ejecutamos mvn package con esta configuración, lo primero que observamos es que, además del directorio estándar de fuentes src/main/java, se habrá creado otro src/main/apt_generated con el código generado automáticamente a partir de las anotaciones. Además, como resultado de la ejecución obtenemos nuestro JAR con todas las clases (originales y generadas) debidamente compiladas.

Hasta aquí, todo perfecto; los problemas comienzan cuando queremos compilar el proyecto en Eclipse…

Normalmente, al importar un proyecto en Eclipse, m2eclipse detecta todos los parámetros de configuración y actualiza los settings del proyecto en consecuencia. Si, por ejemplo, un plugin añade un nuevo directorio de código fuente, m2eclipse, a su vez, lo añade en la configuración del proyecto Eclipse. Como ya digo, esto ocurre en casi todos los plugins pero, por alguna razón, no con el plugin de Tobago. En este caso, al importar el proyecto Eclipse no se entera de que existe el directorio src/main/apt_generated y, en consecuencia, no compila los fuentes generados ni, por supuesto, los incluye en el JAR.

Buscando una solución al problema he encontrado build-helper-plugin que permite, entre otras cosas, añadir directorios de código fuente a nuestro proyecto Maven:

<!--  Añadir el directorio de fuentes donde se generan el código -->
<plugin>
	<groupId>org.codehaus.mojo</groupId>
	<artifactId>build-helper-maven-plugin</artifactId>
	<executions>
		<execution>
			<id>add-generated-source-path</id>
			<phase>generate-sources</phase>
			<goals>
				<goal>add-source</goal>
			</goals>
			<configuration>
				<sources>
					<source>src/main/apt_generated</source>
				</sources>
			</configuration>
		</execution>
	</executions>
</plugin>

Con esto conseguimos que m2eclipse sea consciente de que existe tal directorio y en consecuencia lo configura en Eclipse. Normalmente lo hará al importar el proyecto pero si haces las modificaciones sobre un POM existente deberás utilizar el menú Maven–>Update project configuration^[3].

Así, nuestro proyecto queda perfectamente configurado en Eclipse o para ser lanzado desde la línea de comandos.

Para terminar, también es aconsejable incluir el directorio de fuentes generados en la fase de limpieza de Maven, ya que, por defecto, no se hace:

<!--  Limpiar el directorio de fuentes donde se generan el código -->
<plugin>
	<artifactId>maven-clean-plugin</artifactId>
	<configuration>
		<filesets>
			<fileset>
				<directory>src/main/apt_generated</directory>
			</fileset>
		</filesets>
	</configuration>
</plugin>

1. Existen otras formas mas "artesanales" de hacerlo como, por ejemplo, ésta: http://blogs.steeplesoft.com/maven-and-annotations-not-as-easy-as-it-should-be/
2. No entraremos en los detalles implementación. Si estás interesado en ello puedes consultar la documentación de APT.
3. Si quieres que la carpeta no aparezca en Eclipse para que no se pueda tocar a mano puedes utilizar un nombre precedido de un punto, como ".apt_generated", y de este modo la carpeta quedará oculta