Desarrollo en Web

Como funciona a4j:jsFunction

Giancarlo Corzo — Tue, 19 Oct 2010 22:19:00 +0000

Volviendo a los temas de JSF y Java, hoy día quisiera escribir sobre a4j (Ajax4JSF), una librería que fue integrada al framework Seam y que permite darle una naturaleza AJAX a los componentes JSF tradicionales. En este artículo centraré mi atención en un componente bastante útil denominado jsFunction.

jsFunction es un componente de soporte dentro de la librería y que es usado para poder hacer llamadas asíncronas al servidor desde cualquier código JavaScript que estemos escribiendo. Para tener un punto de referencia podemos decir que se comporta de una manera similar a la etiqueta a4j:commandButton, dado que permite realizar llamadas AJAX al servidor pero de una manera asíncrona.

Veamos un ejemplo:

 type="text/javascript">
     function validateAndSave() {
       if (validate()) {
          save('all');
       }
     }
>
>
  >
     name="save" action="#{myBean.save()}" reRender="listPanel">
         name="param1" assignTo="#{myBean.aParameter}"/>
    >
     id="listPanel">
       ....
    >
  >
>

Cuando se usa a4j:jsFunction es posible iniciar la petición AJAX desde cualquier JavaScript y hacer una actualización parcial de la página o utilizar la información procesada en el JavaScript que se ejecuta de retorno.

Los siguientes escenarios son ideales para usar el componente:

Actualizar registros del lado de la capa Modelo después de cerrar una ventana emergente (popup).
Realizar una operación de guardado de información de manera asíncrona.
Actualizar una variable que será utilizada luego por otro método (ojo con la llamada asíncrona).

Pueden ver un ejemplo completo en la página de demo de RichFaces. (live demo)

Facelets: el atributo rendered de ui:fragment no es reconocido

Giancarlo Corzo — Fri, 17 Sep 2010 22:17:28 +0000

Como programadores especializados en uno o varios lenguajes o frameworks, en ocasiones utilizamos características que no forman parte de la documentación oficial. En esta oportunidad haré alusión a un elemento en Facelets, el atributo rendered de la etiqueta o tag ui:fragment.

La etiqueta ui:fragment

El tag ui:fragment es utilizado para delimitar un conjunto de componentes en función es similar al elemento ui:component, con la salvedad que no elimina el código que existe alrededor de él.

La documentación oficial indica que esta etiqueta sólo posee dos atributos (id y binding); sin embargo en varios artículos se indica la existencia de un atributo adicional, rendered, que hace posible que se muestren o no los componentes dependiendo de un valor condicional. En el siguiente ejemplo se muestra un fragmento de código donde aparece este atributo:

<ui:fragment rendered="#{condition}">
   <h:outputText value="text 1"/>
   <h:outputText value="text 2"/>
   <h:outputText value="text 3"/>
ui:fragment>

¿Cómo es posible que rendered si funcione a pesar de no estar documentado? La razón en realidad es muy simple: los componentes JSF se insertan dentro de un árbol y como tales heredan las propiedades de su componente padre. Por lo tanto, esta excepción funciona porque los componentes hijos heredan el atributo rendered en ui:fragment.

¿Pero si funciona porque busco alternativas?

Los IDEs como NetBeans y Eclipse ya soportan en sus últimas versiones los tags de Facelets y JSF. Estos IDEs resaltan todo texto que no se encuentre conforme a la especificación oficial, y marcaba el código anterior como si se tratase de un error. Es por esta razón que decidí hacer una búsqueda de alternativas para conseguir el mismo resultado.

Entre las alternativas conocidas para esta situación se pueden señalar:

1. Usar otras estructuras agrupadoras:

<s:div rendered="#{condition}">
   <h:outputText value="text 1"/>
   <h:outputText value="text 2"/>
   <h:outputText value="text 3"/>
s:div>

<s:fragment rendered="#{condition}">
   <h:outputText value="text 1"/>
   <h:outputText value="text 2"/>
   <h:outputText value="text 3"/>
s:fragment>

Los tags s:div y s:fragment pertenecen a la librería de tags que provee Seam (http://docs.jboss.org/seam/2.2.1.CR2/reference/en-US/html/controls.html) y son estructuras que agrupan componentes, en el caso de s:div se muestra el contenido dentro de un div mientras que s:fragment es una estructura invisible.

Otra estructura que se puede usar es:

<h:panelGroup rendered="#{condition}">
   <h:outputText value="text 1"/>
   <h:outputText value="text 2"/>
   <h:outputText value="text 3"/>
h:panelGroup>

Si al panel group no se le especifica el valor para id, style o styleClass funciona como entidad agrupada transparente (en caso se le asigne algún valor los componentes se muestran dentro de un span)

2. Usar verbatim si es que el contenido es sólo texto (aunque esto a la larga no es práctico para la mayoría de ocasiones)

<f:verbatim rendered="#{condition}">
   text 1
   text 2
   text 3
f:verbatim>

3. Poner el atributo rendered a cada uno de los elementos hijos:

<h:outputText value="text 1" rendered="#{condition}"/>
<h:outputText value="text 2" rendered="#{condition}"/>
<h:outputText value="text 3" rendered="#{condition}"/>

Con estas tres opciones es posible generar código válido para la versión de JSF 1.2 y no estar dependiendo de ui:fragment como elemento contenedor.

JQuery API browser

Giancarlo Corzo — Wed, 05 May 2010 20:41:58 +0000

Uno de los aspectos más importantes para dominar y hacer uso de una tecnología es tener acceso a buena documentación. En el caso específico de la librería JQuery se cuenta con gran cantidad de información disponible en su sitio web, además de recursos de programadores con ejemplos prácticos de uso.

Sin embargo, la documentación oficial de la herramienta es presentada en páginas independientes, por lo que navegar a través de ellas buscando información específica resulta complicado. Es por ello que quiero compartirles una utilidad que permite encontrar rápidamente mayores detalles de cualquier función de JQuery.

La herramienta, JQuery API browser es accesible de dos maneras: la primera es mediante la aplicación web que utiliza una interfaz AJAX para saltar entre funciones de la librería y la segunda mediante una aplicación de escritorio basada en Adobe Air.

Espero la disfruten tanto como yo lo he hecho.

Usando JQuery Dialog con IFrame

Giancarlo Corzo — Mon, 03 May 2010 22:58:32 +0000

JQuery es una excelente librería JavaScript que simplifica la manipulación del DOM (Document Object Model) de una página HTML, el manejo de eventos, animaciones y AJAX. Así también, desde hace un tiempo atrás provee una librería de componentes UI que extiende los componentes iniciales de esta librería.

El widget de tipo diálogo es un ventana flotante que tiene un título y contenido (similar a un popup). Este widget resulta ser muy útil para mostrar alertas o formularios que el usuario debe llenar antes de poder continuar. Veamos como lograr lanzar un dialog apenas carga la página

 type="text/javascript" src="/assets/javascript/jquery-1.4.min.js">>
 type="text/javascript" src="/assets/javascript/jquery-ui-1.8.custom.min.js">>
 
 type="text/javascript">
 
$(function() {
 $("#dialog").dialog();
});
 
>
 
 id="dialog" title="Basic dialog">
        >This is the default dialog which is useful for displaying information. The dialog window can be moved, resized and closed with the 'x' icon.>
>

Ejemplo tomado de la página web de Jquery

Como puede apreciarse en el código anterior, esta es una solución muy sencilla para hacer un widget dialog; sin embargo, cuando se desarrolla un sistema de mayor complejidad lo ideal es separar las ventanas en múltiples archivos y los diálogos no son la excepción. Una implementación bastante difundida en la web es utilizar un elemento iframe en vez de una etiqueta div para construir el contenido del diálogo. Veamos un ejemplo para que quede más clara la idea.

 type="text/javascript">
 
$(function() {
        $('a.showPopup').click(function(e) {
            e.preventDefault();
            var $this = $(this);
            var horizontalPadding = 15;
            var verticalPadding = 15;
            $(' id="site" src="' + this.href + '" />').dialog({
                title: ($this.attr('title')) ? $this.attr('title') : 'Site',
                autoOpen: true,
                width: 600,
                height: 300,
                modal: true,
                resizable: false,
                autoResize: true,
                overlay: {
                    opacity: 0.5,
                    background: "black"
                }
            }).width(600 - horizontalPadding).height(300 - verticalPadding);
        });
});
 
>
 
 class="showPopup" href="http://www.google.com" title="Google">

Como puede apreciarse en el ejemplo anterior, se utiliza un pseudo iframe, al cual le asignamos la dirección con el contenido que queremos mostrar en el diálogo. Algunas posibles mejoras a esta idea inicial sería crear una función que permita reutilizar el código en otros enlaces, pero eso se los dejo como tarea.

EDIT:
Respondiendo aun pregunta realizada por un lector estoy agregando una manera de cerrar el diálogo desde el iframe mismo:

 type="text/javascript">
var refDialog;
$(function() {
...
refDialog = $(' id="site" src="' + this.href + '" />').dialog(...);
...
});
>

Dentro del iFrame colocar un link de la siguiente manera:

 href="javascript:void(0);" onclick="window.parent.refDialog.dialog('close');">close>

Primeras Impresiones de Django

Pablo Torres Navarrete — Mon, 29 Mar 2010 19:20:50 +0000

Hace poco empezamos a probar Django, uno de los frameworks web más populares para el lenguaje Python. Nos gustaría compartir las características que nos han parecido impresionantes y algunas que no nos han gustado.

Lo más impresionante: el sitio de administración

El “admin site”, como le llaman los Djangonautas, es más que un simple scaffolding para el back-end, puesto que construye una interfaz más avanzada.

Django puede deducir información de los modelos para generar automáticamente las páginas de administración de los objetos de negocio, desde donde se realizan todas las operaciones sobre base de datos: lectura, actualización, creación, eliminación, validación, relación con otros objetos, etc. Así, los usuarios administradores puedan agregar contenido al sitio y tenerla lista para mostrar a los clientes finales.

En unos pocos pasos, explicados en la parte 2 del tutorial, Django ofrece:

El widget correcto a utilizar (combobox, textbox, textarea, etc) para cada campo del objeto de negocio en el formulario de creación y edición.
Atajos inteligentes para los campos: calendarios para las fechas, vínculos de “hoy” y “ahora” para fechas y horas.

Ejemplo de formulario, con validaciones (*)

Listas desplegables para escoger objetos relacionados (a través de llaves foráneas), con un atajo especial para crear un nuevo objeto relacionado en una ventana pop-up en caso éste no exista todavía.
Validación de cada uno de los campos por tipo de dato y longitud.

Ejemplo de filtros y campos de búsqueda (*)

Filtros y criterios de búsqueda para cada objeto, con vínculos de “último mes” y “última semana” para buscar por fecha
Acciones en masa: seleccionar varios objetos y borrarlos a la vez, cambiarles de estado o cualquier acción definida por el programador
Historial de acciones por cada usuario

Ejemplo de usuarios, perfiles y roles

Administración de usuarios, incluyendo perfiles y roles

Una lista bastante larga para un sitio generado automáticamente, ¿no es verdad?

Así, Django nos salva de la tediosa pero infaltable tarea de programar el back-end. Con unas pocas líneas de código, se obtienen páginas listas para mostrar en producción.

(*) Imágenes tomadas del tutorial oficial de Django.

Lo más decepcionante: necesitamos migraciones, ¡urgente!

En Django, un cambio en los modelos no implica un cambio en la base de datos; es decir, el comando ’syncdb’ sólo puede crear tablas, pero no alterar las antiguas.

Los modelos suelen evolucionar con el tiempo, porque cambian los requerimientos o simplemente notamos un error: falta o sobra un campo, o se necesita una tabla extra y una llave foránea. Django no ofrece ningún soporte para estos casos, así que uno se ve obligado a modificar el esquema escribiendo las sentencias SQL a mano. Esto es inconcebible por las siguientes razones:

Algunos de los casos mencionados podrían implicar pérdida o inconsistencia de datos. Es responsabilidad del framework estar alerta de estos errores y proteger al desarrollador de ellos, especialmente si se trata de un tema tan sensible.
Cada motor de base de datos maneja su propia versión de SQL, así que una modificación manual no serviría universalmente.
Una de las tareas de un framework es esconder el lenguaje SQL (es por esto que existen los ORMs).
Django debería ser capaz de manejar al menos los casos más sencillos, como agregar una columna.

En Ruby on Rails, el framework web más popular para el lenguaje Ruby, existe el concepto de “migración“: es posible manipular el esquema de datos a través de código en Ruby, ya sea para crear tablas, agregar columnas o insertar datos. Esta facilidad ofrece muchas ventajas:

Abstracción del lenguaje SQL; es decir, una migración es útil inclusive si se usan distintos motores de bases de datos (por ejemplo, uno ligero para desarrollo y uno más potente para producción, o si la aplicación se desplegó en más de un entorno, cada uno con sus requerimientos sobre bases de datos).
Disponibilidad universal, puesto que las migraciones son archivos que se almacenan en el directorio del proyecto, así que cualquier desarrollador puede acceder a ellas (a través del repositorio) y mantener sincronizada su copia local.
Uso automatizado, puesto que las migraciones son código fuente ejecutable. Esto no es posible si se usara un gestor gráfico para interactuar con la base de datos.
Historial de versiones de la base de datos, puesto que se crea una migración por cada transacción. Así, es posible deshacer o aplicar un conjunto de cambios sobre la base de datos, lo que equivale a mantener el esquema de datos bajo control de versiones (repositorio). Esto no es posible si se usara un gestor gráfico.

Migración para crear una tabla

Django necesita algo similar con urgencia. Por el momento, lo más recomendable es comenzar a utilizar el sitio de administración inmediatamente después de definir los modelos, para poder notar errores lo antes posible y no tener que lidiar con la evolución del esquema. Naturalmente, los desarrolladores de Django ya han comenzado a discutir opciones para salvar este error.

Conclusión

Django es un framework que ofrece muchas abstracciones de alto nivel que simplifican enormemente la tarea del desarrollo web. El ejemplo más claro es la generación automática del back-end, que ahorra muchas horas de labor tediosa.

La documentación es excelente. La curva de aprendizaje de Django es muy baja gracias a la cantidad de información disponible acerca de él, muy bien redactada y muy completa.

El manejo del esquema de la base de datos es un señor problema. A menos que uno sea un experto en SQL (cosa que la “mala” costumbre de los ORMs hace improbable), seguro se tendrán problemas al hacer cambios a las tablas, inclusive cambios sencillos.

Fuentes

Combobox JSF con s:convertEnum

Giancarlo Corzo — Wed, 07 Oct 2009 23:24:42 +0000

Escribo este post para todos los que alguna vez sufrieron buscando un ejemplo claro y simple de como crear un combobox en base a un Enum en JSF y Seam.

La documentación de Seam (tan clara como el agua) nos nuestra el siguiente ejemplo:

 value="#{person.honorific}">
 value="#{honorifics}" 
                       var="honorific" 
                       label="#{honorific.label}" 
                       noSelectionLabel="Please select" />
    />
>

Donde solo muestran el ejemplo puntual sin dar mayor detalle.
Googleando un poco encontré la siguiente página web donde se dan el trabajo de explicar de una manera sencilla como crear el combobox.

En esa página se muestra el siguiente ejemplo:

XHTML:

 id="marketStatus" 
                 value="#{person.status}"
                 required="true">
     value="#{enumLists.statusArray}" 
                   var="status"
                   label="#{status}"
                   noSelectionLabel="Select a status..."/>
    />
>

ENUM:

@Name("enumLists")
@Scope(ScopeType.STATELESS)
public class EnumLists {
   public Status[] getStatusArray() {
     return Status.values();
   }
}

Como se puede ver en el ejemplo han expuesto el Enum como un Seam bean stateless y retornando la lista de valores con status.values().
Para poner un label a cada opción utilizan el toString() del Enum dado que en label colocan label=”#{status}”

Como pueden ver hacer un combobox basado en un Enum es bastante sencillo y útil.

BlogDay 2009: Desarrollo Web recomienda

Giancarlo Corzo — Mon, 31 Aug 2009 22:20:50 +0000

El día de hoy se celebra el día mundial del blog, esto a raíz del parecido entre la fecha 31 de agosto (3108) y la palabra Blog. El movimiento de los blogs ha ido creciendo año tras año y con el tiempo los bloggers se han sumado a publicar sus sitios preferidos.

Es por ello que el día de hoy el equipo que escribe en Desarrollo Web ha dedicado unas cuantas horas a seleccionar y publicar nuestros blogs preferidos. Es así como -siguiendo la tendencia- nos gustaría contribuir con un listado.

Algunas de estas publicaciones son de Desarrollo Web, otras son de temas genéricos pero a la vez recomendables.

joelonsoftware de Joel Spolsky.
Tiene muy buenos posts sobre el desarrollo en general y últimamente sobre sus proyectos personales.
CSSBlog de Pedro Corchero Murga.
Lo encontramos hace poco y nos ha ayudado muchísimo ahora que algunos de los miembros del equipo están revisando temas avanzados de CSS.
Coding horror de Jeff Atwood.
Sus posts más recientes hacen alusión frecuente a la psicología de los programadores.
Sinergia sin control de Ender Wiggins.
Es un blog de un comic para frikis muy divertido.
On Startups de Dharmesh Shah.
Lo llevamos seguimos hace un tiempo y consideramos que se trata de un buen blog sobre negocios.

Si desean compartir otros blogs que suelen visitar pueden hacer comentarios sobre sus blogs preferidos.

Frameworks para iPhone

Giancarlo Corzo — Tue, 04 Aug 2009 14:41:04 +0000

Hace algunas semanas en Antartec se nos encargó desarrollar una aplicación web piloto, ésto no tendría mucha novedad y/o relevancia como para escribir un post sobre ello, sin embargo el objetivo planteado lo hizo particularmente interesante.

El reto en esta aplicación fue desarrollar una web que se comporte como una aplicación nativa de iPhone y que le permita a los usuarios ingresar información en tiempo real al sistema sin encontrarse frente a un computador.

Nuestros esfuerzos se concentraron en expandir nuestro actual framework basado en JSF y SEAM para que soporte el formato iPhone; nuestras investigaciones preliminares dieron frutos y encontramos varios frameworks para simular la apariencia de interfaces nativas en iPhone tales como iUI y UiUI (Universal).

iUI desarrollado por Joe Hewitt es un framework bastante maduro que agiliza la construcción de aplicaciones al manejar las vistas, eventos, peticiones y estilos; sin embargo tiene algunas cosas que no son de mi agrado, como por ejemplo:

Su funcionamiento está dado por el intercambio de vistas o pseudo páginas que se encuentran definidas en un solo documento HTML y mediante manipulación DOM se muestran o se ocultan, para el caso particular de cargar una vista dinámica ésta tiene que ser obtenida por AJAX y reemplazada en la vista apropiada (Ésto no tiene nada de malo pero no se ajusta 100% al ciclo de vida natural de JSF).
La simulación de las transiciones entre vistas que se utilizan en las aplicaciones nativas de iPhone se muestran con saltos bastante antinaturales, ésto se debe a que utiliza los efectos de CSS3 para realizar las transiciones. Es una lástima que en el Safari para iPhone estas transiciones se vean bastante mal debido probablemente a la velocidad del procesador de video del equipo.
Para programar para iUI tienes que aprender la manera en que define vistas, cabeceras, botones etc. Para un proyecto corto, en donde no hay mucho tiempo para aprender, ésto se vuelve un impedimento mas que un beneficio (mi opinión es que mantener un esquema de programación conocido facilita la adopción de la tecnología).

iPhone Universal UI fue otro framework que evaluamos. Desarrollado por Diego Lafuente, se basa en una serie de CSS que simulan la apariencia de las aplicaciones nativas.

Al respetar las convenciones web UiUI se perfilaba como uno de los mejores prospectos para nuestro proyecto dado que podía ser adaptado fácilmente al desarrollo de aplicaciones JSF. Sin embargo, a mi modo de ver tiene una gran desventaja para que sea aceptado por las empresas, tiene una licencia GNU Affero General Public License (GNU AGPL 3) en vez de LGPL que no permite utilizarlo para proyectos con fines comerciales.

Dadas estas circunstancias, decidimos crear nuestro propio framework visual para iPhone que utilice todo el poder de los componentes JSF y el templating de Facelets. En una próxima entrega hablaremos más en profundidad sobre los pormenores del framework.

Maven en detalle – Parte 3

Giancarlo Corzo — Mon, 18 May 2009 22:35:18 +0000

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.

Maven en detalle – Parte 2

Giancarlo Corzo — Fri, 24 Apr 2009 19:44:20 +0000

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:

El id del grupo al que pertenece el proyecto.
El id del artifact o proyecto (en la mayoría de los casos el nombre del proyecto).
La versión del artifact en el grupo especificado.
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.