Continuando con nuestro artículo anterior hoy hablaremos sobre el manejo de las dependencias e IDEs con soporte de Maven.

Problemática

Hasta antes de la aparición de Maven el manejo de las librerías JAR que utilizaba cada proyecto se hacía de manera manual, las librerías normalmente eran almacenadas junto con el código fuente para que no se perdieran.

Muchos de los proyectos manejaban el mismo conjunto de librerías sin embargo éstas se duplicaban por seguridad y porque normalmente el arquitecto era la única persona que sabía exactamente qué versión de librerías debían ser incluidas en cada uno.

Maven resuelve la mayoría de los problemas de administración de las librerías (JAR) mediante un repositorio centralizado y un mecanismo para la inclusión de dependencias.

¿Qué es una dependencia?

Una dependencia es una referencia en el POM de la librería que se desea incluir en el proyecto. Por ejemplo si deseamos incluir la librería para el manejo de JUnit debemos declararlo de la siguiente manera:

<dependencies>
  <dependency>
     <groupId>junit</groupId>
     <artifactId>junit</artifactId>
     <version>4.5</version>
  </dependency>
</dependencies>

Como vimos en el artículo anterior los objetos en el repositorio se identifican mediante 3 tags groupId:artifactId:version

¿Cómo se estructura el repositorio de Maven?

Maven maneja 3 niveles de repositorio: local, empresarial, global.

El repositorio local normalmente conocido como .m2 se guarda localmente en nuestra pc (En Windows se almacena en “documents and settings” y en linux en nuestro “home”). Dentro de ella encontramos los JAR, WAR, etc en una jerarquía de carpetas que siguen el mismo concepto groupId:artifactId:version.

Veamos un ejemplo de un repositorio local estándar:

El repositorio Empresarial tiene la misma estructura que el repositorio local con la diferencia que almacena librerías de uso compartido a nivel de red. Los repositorios empresariales normalmente se utilizan cuando se maneja un equipo de desarrolladores que trabaja sobre un conjunto variado de proyectos, los cuales normalmente tienen interdependencia entre ellos y sus librerías.

Los repositorios globales son repositorios públicos que almacenan librerías de uso compartido, como por ejemplo el repositorio mismo de Maven o el repositorio público de JBoss o maven central.

Cuando el proceso de compilación busca las dependencias del proyecto lo primero que hace es buscarlas en el repositorio local, si no las encuentra recurre a sus repositorios empresariales (definido en un archivo .settings.xml) o de red y en caso de no encontrar ahí los JAR necesarios los busca en los repositorios globales.

Es importante notar que una vez ubicado un JAR en alguno de los repositorios externos Maven inmediatamente lo descarga al repositorio local por lo que si uno desea que siempre se actualice el JAR de los repositorios externos debe incluir –U en el comando (ejemplo mvn clean install –U ).

El uso de repositorios Empresariales está íntimamente ligado al uso de la metodología de integración continua por lo que les recomiendo leer la entrada Integración continua.

Ámbito de las dependencias

Existen seis ámbitos en los que una dependencia puede ser declarada limitando así su transitividad:
Compile, es el ámbito por defecto. Las dependencias están disponibles en el proyecto y en sus proyectos dependientes.
Provided, se espera que el JDK, la aplicación o el contenedor provea la dependencia.
Runtime, la dependencia no es requerida en tiempo de compilación pero sí para la ejecución.
Test, son dependencias que son requeridas solo cuando se compila y ejecuta los test.
System, similar a provided pero se le debe indicar el jar que contiene la dependencia
Import, (a partir a la version 2.0.9) solo es usado en una dependencia del tipo POM en la sección . Indica que el POM utilizado debe ser remplazado con las dependencias que éste tenga en su sección

Cómo usar maven en Netbeans

En Antartec usamos Netbeans como la plataforma por defecto para el desarrollo de aplicaciones web al proveer de manera integrada la mayoría de componentes necesarios para nuestro trabajo.

Pasos para trabajar en Netbeans con Maven

1. Instalar Netbeans (Lo pueden desargar de www.netbeans.org)
2. En el menú seleccionar Herramientas – plugins
3. En la sección “Plugins disponibles” seleccionar el plugin Maven y hacer clic en Instalar.
4. Reiniciar el netbeans, con eso netbeans reconoce y permite crear proyectos maven desde cero.

Continuando con nuestro artículo anterior analizaremos la estructura del proyecto y el POM, base de todo proyecto Maven.

La estructura del Proyecto

Dependiendo del tipo de proyecto se pueden tener diferentes estructuras, sin embargo las estructuras más conocidas son la JAR y la WAR.

Veamos la estructura de una aplicación JAR:

Veamos la estructura de una aplicación WAR:

Como puede verse las estructuras son parecidas con la diferencia que la estructura WAR tiene la sección webapp donde irán todos los files jsp, xhtml, html, etc.

En el directorio resources van files de configuración así como el messages.properties.

El POM (Project Object Model)

El POM file es el archivo XML de configuración de cualquier proyecto Maven, en él podemos encontrar información sobre la versión y las dependencias del proyecto así como cualquier otra configuración personalizada para ese proyecto.

El contenido del POM generado después de ejecutar el comando lo podemos ver a continuación:

<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/xsd/maven-4.0.0.xsd">
   <modelVersion>4.0.0</modelVersion>
   <groupId>com.antartec.app</groupId>
   <artifactId>my-test</artifactId>
   <packaging>jar</packaging>
   <version>1.0-SNAPSHOT</version>
   <name>Maven Quick Start Archetype</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>

Veamos los tags más importantes:

<groupId> El id del grupo al que pertenece el proyecto.
<artifactId> El id del artifact o proyecto (en la mayoría de los casos el nombre del proyecto).
<version> La versión del artifact en el grupo especificado.
<dependency> Aquí se colocarán todas las dependencias del proyecto.

El POM requiere que estos valores estén definidos ya que ésta es la manera en que Maven los identifica dentro de su repositorio.

Ej. groupId:artifactId:version com.antartec.app:my-test:1.0-SNAPSHOT

Si no se especifica algunos de los tags (packaging,  name,  url) maven usan los valores por defecto heredados del super POM del cual heredan todos los proyectos (hablaremos sobre la herencia más adelante).

Construyamos el proyecto

Ejecutando el siguiente comando se construye el proyecto:

mvn clean install

A diferencia del comando archetype:create este comando es de una sola palabra que especifica la fase que debe ejecutarse. Una fase corresponde a un paso del ciclo de vida de maven. Por ejemplo

mvn compile

Ejecutará las siguientes fases:

validate
generate-sources
process-sources
generate-resources
process-resources
compile

Existe muchas fases en Maven sin embargo listo las más utilizadas a continuación:

• validate – valida que el proyecto es correcto y tiene toda la información necesaria.
• compile – compila el código fuente.
• test – compila el código y ejecuta los unit test correspondientes. Sin embargo no es requisito para que el proyecto sea desplegado.
• package – toma el código compilado y lo empaqueta en un formato distribuible como JAR o WAR.
• integration-test – Despliega el proyecto si es necesario en ambiente de pruebas donde se puedan correr pruebas de integración.
• verify – ejecuta cualquier verificación para cumplir los parámetros de calidad.
• install – instala el jar o war en el repositorio local para que otras aplicaciones locales la puedan usar.
• deploy – copia el jar o war a un repositorio remoto para que pueda ser usado por otro desarrollador o proyecto.

Si desean ver la lista completa de fase las pueden encontrar en lifecycle

Para un desarrollo local bastará con utilizar mvn clean install.

En nuestra siguiente entrega hablaremos sobre el manejo de las dependencias y como usar el proyecto junto con nuestro IDE favorito.

Comenzamos la saga Maven compuesta por una serie de artículos en donde detallaremos como instalar, construir, desplegar un pequeño proyecto piloto.

En artículos anteriores hemos hablado sobre las ventajas de Maven y como es que éste encaja dentro la de estructura de integración continua en el desarrollo de proyectos por lo que pasaremos directamente a los detalles.

Empecemos por instalar Maven

Tenemos que ir al sitio web de la Maven y descargar la última versión (http://maven.apache.org/download.html),  es necesario contar con el JDK previamente instalado.

Seguimos las instrucciones de la página para configurar las variables de entorno correspondientes para máquinas con Windows o Linux.

Una vez instalado, construiremos nuestro primer proyecto

Una vez instalado maven en nuestro computador podemos empezar por construir nuestro primer proyecto de prueba al cual llamaremos app-test.

Ejecutamos el siguiente “Archetype” para crear un jar en la línea de comandos:

mvn archetype:create
-DarchetypeGroupId=org.apache.maven.archetypes
-DgroupId=com.antartec
-DartifactId=app-test

Los archetype son simples plugins de maven, uno de ellos es el archetype create, el cual permite crear un proyecto base al proporcionar la plantilla del mismo.

El archetype create recibe una serie de parámetros los cuales son:

• archetypeGroupId, usar este parámetro es una manera abreviada de crear un proyecto de tipo jar, sin embargo cuando se usan archetypes creados por uno mismo se tiene que especificar los tres parámetros de todo archetype (groupId, artifactId,version) de la siguiente manera.

mvn archetype:create
-DarchetypeGroupId=<archetype-groupId>
-DarchetypeArtifactId=<archetype-artifactId>
-DarchetypeVersion=<archetype-version>
-DgroupId=<my.groupid>
-DartifactId=<my-artifactId>

• groupId, es usado como identificador del conjunto de librerías en este caso hemos usado com.antartec como  nombre para nuestro paquete de librerías.
• artifactId, es usado como identificador particular de una librería en particular.

Si es la primera vez que se ejecuta un comando Maven éste tomará algo de tiempo pues Maven creará el repositorio inicial .m2 y descargará todas las librerías necesarias para construir el proyecto.

Si deseamos crear un proyecto war en vez de un jar ejecutaremos el siguiente “Archetype” en la línea de comandos:

mvn archetype:create
-DarchetypeArtifactId=maven-archetype-webapp
-DgroupId=com.antartec.app
-DartifactId=webapp-test

En este caso hemos ejecutado un archetype distinto que contiene la plantilla de un proyecto web.

En el siguiente artículo analizaremos la estructura del POM generado, base de cualquier proyecto Maven.

En este post me gustaría hacer una pequeña contribución al post “Performance: ¿Por qué usar @Factory en vez de getters?” de Seam City sobre el uso de @Factory para la obtención de listas.

En el post se menciona que los valores obtenidos por EL no se guardan en cache y ésto es un problema sobre todo cuando se acceden a listas que son cargadas desde la base de datos.

Para resolver el problema el post plantea 2 opciones:

Por patrón de carga lazy loading

@Name("userManager")
public class UserManager {
  private List list;
 
  public List getUserList() {
    if (this.list == null) {
      this.list = createUserList();
    }
    return list;
  }
}

Y una mejor manera utilizando las anotaciones @Out y @Factory

 
public class UserManager {
 
  @Factory(value = "userList", scope = ScopeType.PAGE)
  public List getUserList() {
     if (this.list == null) {
       this.list = createUserList();
     }
     return list;
  }
}

Sin embargo existe una tercera solución que es bastante más clara y sobre todo sigue la convención con respecto a la creación de objetos y es utilizar la anotación @Create

El código es el siguiente:

 
@Name("userManager")
@Scope(ScopeType.PAGE)
public class UserManager implements Serializable {
 
  private List<User> list;
 
  @Create
  public void loadInitData() {
     this.list = createList();
  }
 
  public List<User> getList() {
    return list;
  }
 
   public void setList(List<User> list) {
     this.list = list;
   }
}

La anotación @Create nos permite declarar que un método se ejecute al momento que un componente es creado. Momento apropiado para cargar toda la información que sólo debe ser obtenida una vez.

La anotación @Scope(ScopeType.PAGE) nos permite establecer un contexto para el componente de seam, en este caso que el componente exista mientras la página esta activa. Se pueden utilizar otros contextos como por ejemplo Conversation o Session, sin embargo no es recomendable usar el contexto session a menos que sea estrictamente necesario pues sin una adecuada adminstración la memoria requerida por aplicación puede dispararse.

A modo de conclusión

Es una buena práctica centralizar la información de carga estática en un solo método y combinado con el scope Page mejor, pues el uso de memoria en el servidor es mínimo.

Introducción

Las ventanas Pop up siempre han sido un problema en el desarrollo de aplicaciones web, las que proporciona el browser son poco prácticas al ser mini ventanas que se abren de manera separada a la aplicación, en un browser independiente y que no comparten información de manera natural. (Solamente mediante javascript).

Además recientemente éstas han sido utilizadas como una manera de spam publicitario al activarse al momento de ingresar a la página web, lo que hace que la navegación sea realmente molesta. Dada esta situación los browser decidieron desarrollar sistemas que bloqueen los Pop ups de toda aplicación sin importar si estos eran relevantes o no.

Es por esto que multiples frameworks de javascript como yui, ext, richfaces (aunque no es de javascript tambien provee Pop up windows) han desarrollado Pop up windows basados en un div flotante y que son bastante útiles.

¿Qué hace que un Pop up window sea realmente útil?

Un Pop up window utilizado dentro de una aplicación es útil en la medida en que pueda cumplir los mismos requerimientos que tendría un Dialog hecho en Java o C#.

Por lo tanto las características que deben tener son:

• Deben poder ser invocados desde cualquier lugar (en este caso desde cualquier página web).
• Ser autocontenibles (que no se necesite registrar información extra para que funcionen).
• En caso que necesiten retornar parámetros, estos debe poder ser obtenidos en la página que lo llamo.
• Una extensión del punto anterior seria que los Pop up window puedan intercambiar información entre ellos.
• Capacidad de recibir parámetros.

Nuestra solución

Hemos planteado nuestra solución de la siguiente manera:

Para cumplir con el primer y tercer objetivo tenemos un objeto javascript que es omnipresente a todas las páginas y se encarga de: crear, mostrar y cerrar los Pop up y además maneja los parámetros de retorno.

Para cumplir con el segundo objetivo el contenido del modal panel esta en otra página web y ésta es mostrada a través de un iframe dentro del modal.

Para cumplir con el quinto objetivo simplemente se los pasamos como parámetros de url a la página dentro del iframe.

Un ejemplo de cómo instanciamos un objeto:

function editarObjeto(id) {
  ManejadorVentanas.mostrar({
   id: 'idPanel',
   titulo: 'Editar objeto',
   src: '/contenido/editarObjeto.xhtml?id=' + id,
   ancho: 500,
   alto: 350,
   callback: refrescarLista
 });
}

Como puede verse la invocación es muy sencilla y solo se requiere tener la página en donde se desarrollará el contenido.

La función de callback permite obtener los parámetros de retorno, de esta manera:

function refrescarLista () {
   var rpta = ManejadorVentanas.obtenerParametros('idPanel')['rptaModal'];
   if (rpta) {
      var valorRetornado = ManejadorVentanas.obtenerParametros('idPanel')['valor1'];
 
      // hacer algo mas.
   }
 }

A manera de conclusión

No importa con que librería de javascript estén trabajando (YUI, JQuery, ExtJS, Dojo, etc) estos principios básicos deben poderse cumplir para poder sacar el máximo provecho de las Pop up windows dentro de una aplicación web.