Con esta nueva versión, y con el uso del nuevo cliente desarrollado para PHP, se permitirá a los integradores incorporar en sus portales los servicios de Autenticación haciendo uso del DNIe y, por supuesto, del resto de Certificados Digitales que ya veníamos soportando.

En casa ya nos estamos beneficiando de esta nueva versión, integrando nuestras plataformas Moodle (e-learning para uso interno) y Drupal (cms) con Viafirma para autenticarnos con el DNIe. Otros desarrollos específicos en PHP, como TimeTracker (control de imputaciones horarias), también han sido integrados para permitir el acceso mediante DNIe.

• http://www.e3l.es/
• http://www.eterproject.org/

La Consejería de Medio Ambiente de la Junta de Andalucía ha apostado fuerte por la iniciativa y como resultado de ello confió en VIAVANSI para construir Augi@s, un sistema integral de gestión de residuos pionero al hablar E3L. Augi@s permite completar el ciclo de un documento desde su creación hasta su presentación y firma. El sistema ha sido diseñado para hablar en lenguaje E3L; por ello, el equipo de proyecto, constituido por personal de la Consejería de Medio Ambiente y de VIAVANSI, ha participado en la definición del estándar durante su desarrollo. Esto supone al fin una garantía de futuro para el formato de los datos manejados por Augi@s.La aplicación está diseñada con la máxima flexibilidad posible, externalizando en un API independiente la gestión del formato E3L, permitiendo adaptarse a los cambios del mismo en poco tiempo, o integrar nuevos elementos como los servicios publicados en E3S, que ya se encuentran en fase de pruebas en Augias.Considerando la aceptación del formato E3L a nivel estatal y la posibilidad de exportar dicho formato a otros países de la UE, podemos decir que la plataforma Augi@s se encuentra en una posición privilegiada de cara al futuro y vuelve a demostrar que, en contra de lo que se supone en varios círculos de opinión, Andalucía suele liderar a nivel nacional la innovación en muchos proyectos tecnológicos.

En él se recogen una serie de directrices que pretenden ser un conjunFto de normas o pautas a los que las Administraciones Públicas han de ajustarse con el objetivo de permitir y favorecer  la interoperabilidad entre los distintos sistemas de información dentro de la propia Administración.

Podeis ver una introducción AQUI

Y de forma más extendida en el B.O.E.

Este Real Decreto no abandona una visión distribuida de los diferentes sistemas de información, donde cada Administración puede dar respuesta a determinados problemas que sólo surgen dentro de un ámbito muy concreto. Pero por otro lado puede ser muy útil para evitar la reinvención de la rueda, es decir, de soluciones que pueden ser aplicadas en distintas situaciones, algo muy común a día de hoy quizás por desconocimiento, quizás por “desorganización” dentro de la propia Administración.

Este texto apuesta claramente por una publicación vía electrónica de todos los servicios de la Admón. de forma organizada a través de Inventarios, gestionados por las Administraciones locales pero a su vez que se integren dentro de un Inventario a nivel Nacional, sin olvidar en ningún momento el aspecto Semántico de los diferentes servicios.

Se hace un guiño a favor del uso de estándares abiertos y de herramientas genéricas, pero a su vez, se puntualiza que se puedan usar otros con la finalidad de favorecer el acceso al ciudadano y el no estancamiento tecnológico.

La Firma y Certificados Electrónicos se ha convertido en una herramienta muy útil y funcional, y como no podía ser de otra forma encontramos un amplio apartado dedicado a esto aplicado a la relación entre sistemas consumidores y publicadores de los distintos servicios.

Sobre los Documentos Electrónicos, se hace referencia al almacenamiento y disponibilidad de dicho documento, siempre bajo unas reglas de seguridad sin pasar por alto la famosa LOPD, siguiendo las principios de integridad, autenticidad, confidencialidad, etc. Se habla también de los formatos en que ha de almacenarse los documentos y de la digitalización de los documentos en soporte papel.

Sin duda, vemos que éste es un texto bastante genérico y más que ser una enumeración de normas/estándares concretos, algo que sería cuanto menos utópico si hablamos a nivel nacional,  se trata de una apuesta y declaración de intenciones bastante condundente.

Después de haberle dedicado unos minutos a este texto y cuál sería su implicación a nivel autonómico, más concretamente en Andalucía, sin duda alguna se me viene a la cabeza una palabra: PLATINA. Desde hace algún tiempo la Administración Andaluza ya viene observando la problemática de tener un batiburrillo de servicios muchas veces difícil de conectar entre si y viene apostando por esa plataforma como “anillo único para unirlos a todos”.

Sin duda, la interoperabilidad entre sistemas,  es un tema que quizás al inicio de los tiempos no se veía tan necesario, pero si no hemos abordado ya a día de hoy: ¡vamos tarde!

“Estoy seguro de que nos olvidamos de algo, y sé que tenemos algunos conflictos pendientes. Al mismo tiempo, necesitamos la cobertura de una versión real, y en su conjunto tiene muy buen aspecto. Hemos corregido unos cuantos conflictos en los últimos días, y siempre tendremos las versiones 2.6.30.x (parches).“

Pues este es precisamente el mensaje con el Linus Torvalds dio a conocer la versión 2.6.30 del Kernel de Linux!! (el mensaje original en: http://lkml.org/lkml/2009/6/9/710). Sería impensable que le dijéramos una frase similar a un cliente.

Salvando los posibles problemas con clientes que “entren en pánico” debido a este derroche de sinceridad, y ahora que está tan de moda las políticas de calidad, objetivos, métricas, … Nuestro objetivo es que la calidad de nuestras aplicaciones esté tan demostrada, que en una situación puntual le podamos decir a un cliente una frase tan sincera como ésta, sin que el cliente sienta ningún tipo de angustia.

Sector Público

Como no podía ser de otra forma, nuestro repaso empezará por la implantación con mayor número de operaciones realizadas, es decir, la implantación de Viafirma en la Fundación Tripartita para la Formación en el Empleo.

Fundación Tripartita

En apenas 10 meses desde su paso a producción, han superado los 2,6 millones de transacciones, entre autenticaciones y firmas, tal y como se resumen en las siguientes gráficas.

Las operaciones fueron realizadas con certificados digitales de varias Autoridades Reconocidas por la plataforma, entre ellas, FNMT, DNIe, Camerfirma, Izempe, Ancert o ANFAC, pero sin duda, el grueso de operaciones fueron realizadas por los certificados de empresa de la FNMT, tal y como se muestra en la siguiente gráfica.

Ratios de Efectividad

Las siguientes gráficas muestran el ratio de efectividad de las autenticaciones y firmas completadas. Si tenemos en cuenta que para estas métricas se tomaron valores de cierre de sesión sin finalizar el proceso de firma o autenticación (por ejemplo, un usuario se autentica en el sistema, y por cualquier motivo ajeno al sistema, decide cerrar sin firmar el documento solicitado), estos resultados demuestran un excelente comportamiento.

Ratio de Efectividad en Autenticaciones

Junta de Andalucía

La Junta de Andalucía está estudiando la utilización de Viafirma como cliente de autenticación y firma digital. Gracias a ese uso la Junta de Andalucía se beneficiaría de la usabilidad y neutralidad tecnológica que caracteriza a Viafirma, tal y como se recoge en nuestra Matriz de Compatibilidad, probablemente una de las más completas del mercado.

Estas implantaciones se sumarían a otras implantaciones en el sector público realizadas en República Dominicana, donde organismos como la Direcc. Gral. de Impuestos Internos (DGII - el equivalente a la Agencia Tributaria), o el Ministerio de Educación Superior, Ciencia y Tecnología (SEESCyT) ya hacen uso de Viafirma para completar transacciones de autenticación y firma mediante el uso de Certificados Digitales reconocidos por el INDOTEL, órgano regulador.

Sector Educativo

A la implantación de Viafirma el año anterior en la Universidad Iberoamericana (UNIBE), en este 2009 se le suman las implantaciones de Viafirma en la Universidad de Extremadura y la Universidad de Cádiz, que dispondrá de un escritorio centralizado de firmas.

Sector Productivo

Toyota España integró su ERP con Viafirma para gestionar la firma electrónica de todas sus facturas, haciendo uso del formato facturae 3.1 que ofrece Viafirma, siendo reconocida por la propia Agencia Tributaria como solución compatible con el formato homologado.

En las Islas Baleares, su Colegio de Farmacéuticos (COFIB), completó la integración con Viafirma de su sistema de gestión para la Receta Electrónica.

Alianzas

En este 2009 afianzamos colaboraciones comerciales y técnicas con la Autoridad de Certificación Firmaprofesional. También extendimos nuestra relación comercial en el mercado latinoamericano, con colaboraciones en Chile, Panamá, Costa Rica y República Dominicana.

Roadmap

En 2010 Viafirma continuará con la incorporación de nuevas funcionalidades, nuevos formatos de firma, nuevas Autoridades de Certificación reconocidas. Las mejoras introducidas durante este año que terminamos, y las que incluiremos en el próximo, sólo son posibles con el apoyo mostrado en todas nuestras implantaciones, también reflejado en los numerosos correos de apoyo y felicitaciones recibidos y, como no, gracias al excelente equipo que hay detrás de Viafirma.

Por todos ellos, gracias y feliz entrada de año 2010 !!

sudo apt-get install odt2txt

Una vez que está instalada, ya se puede integrar en distintos scripts que hagan lo que necesitemos. Por ejemplo, para localizar los ficheros odt que contienen una cadena de texto dentro de una carpeta y sus subdirectorios podemos utilizar el siguiente:

#!/bin/sh
for i in `find . -name *.odt`; do
if [ `odt2txt "$i" | grep -iE "$@" | wc -l` -gt 0 ]; then
echo "Texto encontrado en $i"
fi
done


que se utilizaría de la siguiente manera:


$ ./find_in_odt.sh "cadena de texto a buscar"


El script anterior cuenta con la limitación de que no está preparado para funcionar con carpetas cuyo nombre contiene espacios. Otra opción podría ser la búsqueda de diferencias entre dos ficheros:

#!/bin/sh
odt2txt $1 > tempfile1
odt2txt $2 > tempfile2
diff -u tempfile1 tempfile2
rm tempfile1 tempfile2


ejecutable como (recomiendo instalar colordiff para ser usado en lugar del diff tradicional):

$ ./odtdiff.sh fichero1a.odt fichero1b.odt

Más aún: podemos integrar odt2txt con sistemas de control de versiones como Git (usado por el kernel de Linux, Gnome, Android o Ruby on Rails entre otros) para conseguir integración con ficheros de OpenOffice (útil para ver los cambios entre las diferentes versiones en el repositorio). Para ello, basta con añadir al archivo de configuración .gitconfig (presente en el directorio de usuario en Linux y OSX)

[diff "odf"]
textconv=odt2txt
y luego, dentro del repositorio del proyecto, crear o modificar el archivo .git/info/attributes para que contenga


*.ods diff=odf
*.odt diff=odf
*.odp diff=odf


Espero que alguno de estos consejillos os sirva de utilidad, ¡un saludo!

Visto en Con Código

¿Por qué es importante esta liberación?

• Por fin tenemos un estándar Java para la inyección, publicación, localización y búsqueda de componentes.
• Promete una mejor orquestación entre componentes JEE, evitando los típicos problemas de interoperabilidad entre Beans Spring, componentes Seam, Wicket, JSF, EL, etc..)
• Un remplazo estándar a las diferentes soluciones de inyección e IoC como Spring IoC, el prometedor Google Guice o el muy utilizado por nosotros Jboss Seam annotations.
• Fin del infierno XML, definiendo un mecanismo estándar independiente de ficheros de definición XML, que junto con JSF 2.0, Servlet 3.0, JPA, Jax-ws, etc… simplifican el desarrollo JEE.

¿Consecuencias para la industria a medio plazo?

• Es demasiado pronto para saberlo, pero…
  ¿Quizás el fin de la guerra de frameworks se inyección?…. (Google Guice vs Spring vs Jboss Seam). Consiguiendo un efecto similar al que consiguió JPA/JDO estandarizando el acceso a datos.
• Por fin una especificación JEE con la que construir aplicaciones complejas de forma sencilla.
• En un momento en el que muchas organizaciones están intentando estandarizar sus desarrollos, llegando incluso a restringir o imponer las tecnologías utilizadas, la preselección de implementaciones como Spring IoC o Seam carecerá de sentido. Siendo mucho más coherente la recomendación de estándares en lugar de restringir la evolución natural de la tecnología y la sana competición entre sus diferentes implementaciones.

¿Consecuencia para nosotros?

• Ninguna…. Gracias a nuestra apuesta por Jboss Seam (desde hace ya unos años), esta especificación se encontraba ya en nuestra hoja de ruta antes incluso de que fuese un Draft, por lo que para nosotros será suficiente con una mínima adaptación al estándar.
• La implementación es estable, la especificación muy bien pensada, y en las pruebas que hemos realizado con la beta, ha demostrado que consigue simplificar los desarrollos y hacer más comprensible el “oscuro arte de la inyección de componentes”.
• En breve empezaremos a usarla en algún proyecto piloto (que pueda asumir el riesgo de I+D asociado), analizaremos en detalle los posibles problemas que puedan surgir, y si todo se comporta como promete a mediados de 2010 empezaremos a usar la nueva especificación en nuestros proyectos Java.

¿Defectos?

• Llega demasiado tarde. Otros frameworks llevan, aunque de una forma mucho menos limpia,  ofreciendo algo similar desde hace ya mucho tiempo.
• Todavía no conocemos sus defectos. Y eso es un gran problema ya que hasta que no conozcamos sus problemáticas asociadas no será seguro su uso en proyectos de envergadura.
• Esperemos que en la huida del infierno de los ficheros de configuración XML, no nos metamos en  las tinieblas del uso de inyección e IoC para todo. Ya que una aplicación con una gran cantidad de componentes, comportamientos o atributos que dependen de la inyección hace muy complicada la comprensión de su funcionamiento.

En definitiva, todo indica que estamos antes una de las piezas clave del próximo JEE 6.

El objetivo de este artículo es servir de guía básica para la migración manual de proyectos Java no Maven a entorno Maven. Pensado y dirigido especialmente a personas con poca  experiencia previa en Maven, pero con algún conocimiento previo.

Preparación del proyecto

Como es obvio, para migrar un proyecto Java a Maven, deberemos disponer de sus fuentes y todas las librerías dependientes.

Ya que vamos a realizar modificación estructurales importantes en el proyecto, conviene asegurarnos de que los fuentes no están conectados a ningún sistema de control de versiones como Subversion. Para realizar esto, podemos o bien eliminar manualmente todos los directorios .svn de nuestro proyecto o bien desde Eclipse desconectar el proyecto.

Si lo vamos a realizar de forma manual, debemos asegurarnos de eliminar todos los directorios .svn (o .CVS si el proyecto a migrar estuviese conectado a un CVS) A modo de ejemplo, en Linux podemos ejecutar el siguiente comando desde el directorio del proyecto para eliminar todas las referencias a carpetas ‘.svn’:

rm -rf `find . -type d -name .svn`

Será mucho más sencillo hacerlo de forma automática desde Eclipse. Para desconectar el proyecto, teniéndolo seleccionado pulsaremos sobre el botón derecho del ratón: Team -> Disconnect.

Adaptación del proyecto

Aunque la estructura por defecto Maven puede ser modificada, es muy recomendable adaptar la organización del proyecto a migrar a la estructura por defecto más generalizada:

Para hacer esta modificación de la estructura hay que tener especial cuidado en algunos aspecto o convenciones Maven:

• Los ficheros de recursos: Maven hace una distinción entre los ficheros de clases java y los ficheros de recursos .properties y XML’s y, de hecho, salvo que le digamos lo contrario, no hará ningún tratamiento de los ficheros no java que se encuentren en el directorio src/main/java. Por este motivo, tendremos que localizar todos los ficheros de recursos (properties, XML’s) que se encuentran en el directorio java y moverlos al directorio resources (src/main/resources).
• Eliminar la carpeta classes. Es muy común que proyectos no Maven tengan en su carpeta WEB-INF/classes los compilados del proyecto. Esta situación no sólo no es recomendable sino que puede producir problemas, por lo que los eliminaremos confiando en Maven para su generación cuando sea necesario.

Definir el pom.xml del proyecto

Una vez que la estructura del proyecto se ha adaptado a la filosofía Maven, el siguiente paso es definir el pom.xml del proyecto.

Partiremos de un fichero pom.xml básico. Este fichero de origen no tiene dependencias; durante el proceso lo adaptaremos y posteriormente iremos refinando la configuración hasta alcanzar una “mavenización” completa del proyecto.

Una vez colocado el pom.xml en el raíz de la aplicación, lo modificamos indicando el nombre del proyecto y la información básica relativa a los desarrolladores, organización y repositorio de dependencias utilizado.

Antes de continuar y añadir las dependencias, podemos hacer una comprobación previa y verificar que efectivamente nuestro IDE, en este caso Eclipse, reconoce correctamente la nueva estructura del proyecto.

Para ello nos vamos a la consola y en el directorio en el que se encuentra nuestro proyecto ejecutamos la siguiente orden:

mvn clean eclipse:eclipse

(Requiere disponer de Maven correctamente instalado en la máquina).

Si la configuración del entorno es correcta, obtendremos una salida similar a esta:

[INFO] Scanning for projects…
[INFO] Searching repository for plugin with prefix: ‘eclipse’.
[INFO] ————————————————————————
[INFO] Building ejemplo
[INFO]    task-segment: [clean, eclipse:eclipse]
[INFO] ————————————————————————
[INFO] [clean:clean]
[INFO] Deleting file set: /home/felix/workspaces/ejemplo/target (included: [**], excluded: [])
[INFO] Preparing eclipse:eclipse
[INFO] No goals needed for project - skipping
[INFO] [eclipse:eclipse]
[INFO] Adding support for WTP version 1.5.
[INFO] Using source status cache: /home/felix/workspaces/ejemplo/target/mvn-eclipse-cache.properties
[INFO] File /home/felix/workspaces/ejemplo/.project already exists.
       Additional settings will be preserved, run mvn eclipse:clean if you want old settings to be removed.
[INFO] Wrote Eclipse project for “ejemplo“ to /home/felix/workspaces/ejemplo.
[INFO]
       Sources for some artifacts are not available.
       Please run the same goal with the -DdownloadSources=true parameter in order to check remote repositories for sources.
       List of artifacts without a source archive:
         o javax.servlet:servlet-api:2.4
         o javax.servlet.jsp:jsp-api:2.1
         o junit:junit:3.8.1 

[INFO] ————————————————————————
[INFO] BUILD SUCCESSFUL
[INFO] ————————————————————————
[INFO] Total time: 4 seconds
[INFO] Finished at: Wed Sep 3 11:54:28 CET 2008
[INFO] Final Memory: 10M/80M
[INFO] ————————————————————————

Nos vamos a Eclipse, refrescamos el proyecto (F5 teniendo seleccionado el proyecto) y comprobamos que la nueva estructura es correcta.

Ahora que hemos comprobado que eclipse ha reconocido la nueva estructura, el siguiente paso es definir en nuestro pom.xml las dependencias. Para hacer esto eliminamos todos los .jar que se encuentran en el directorio /WEB-INF/lib y nos quedamos con una copia de ellos para posteriormente ir resolviendo las dependencias del proyecto original. Una recomendación es cortar la carpeta /WEB-INF/lib a otra ruta de nuestro disco.

Resolución de dependencias

Esta es la fase más delicada del proceso, ya que debemos asegurarnos de que todas las dependencias del proyecto quedan correctamente declaradas en el fichero pom.xml. Para realizar esta tarea es recomendadle utilizar alguna aplicación web que nos ayude a la localización de las librerías, como por ejemplo MvnRepository o MvnBrowser (recomendada), en la que podremos buscar cada uno de nuestros jar y encontrar la definición en el pom.xml que debemos utilizar.

Gracias a esta web, una vez que tengamos localizada la dependencia, solo tendremos que copiar el bloque POM Dependency a nuestro fichero pom.xml.

Iremos repitiendo este proceso de forma iterativa para todos nuestras librerías .jar y añadiendo la definición de la dependencia a nuestra zona de dependencies, con ciertas salvedades y consideraciones que introducimos a continuación.

Consideraciones especiales

Hay ocasiones en las que determinar la definición de la dependencia en nuestro pom.xml puede no ser una tarea trivial. Se comentan a continuación los mecanismos de actuación recomendados según diversas casuísticas:

• No se indica la versión de la librería en el nombre del fichero.

Por ejemplo, podemos encontrarnos una librería llamada axis-ant.jar, por lo que tendremos que averiguar previamente la versión de la librería de cara a definir la dependencia en el fichero pom.xml. Para esto suele ser muy efectivo descomprimir la librería y consultar el fichero /META-INF/MANIFEST.MF. A modo de ejemplo, en dicha librería mencionada observaríamos una linea similar a la siguiente: “Implementation-Version: 1.2.1 2243 June 14 2005″. Una vez que conozcamos la versión podremos realizar la búsqueda de la forma usual. , 1.1.1.1. Sabemos que la librería fue generada por maven, pero no conocemos su definición.

No conocemos el groupId, artifactId, etc. Podemos descomprimir el .jar y acceder al fichero pom.xml que se encuentra en /META-INF/maven para comprobar el groupId, artifactId y versión de la dependencia.

• Dependencias especiales JEE.

Algunos jars, como por ejemplo servlet.jar, son aportados por el contenedor de aplicaciones, por lo que tendremos que definirlas marcándolas como provided. Esto le indica a Maven que estas librerías pueden ser utilizadas en tiempo de compilación, pero no serán agregadas al empaquetado final. Para declarar una dependencia de esta forma incorporaremos en nuestro pom.xml un código como este:

<dependency>
      <groupId>javax.servlet</groupId>
      <artifactId>servlet-api</artifactId>
      <version>2.4</version>
      <scope>provided</scope>
</dependency>

• Librerías ya consideradas en las dependencias transitivas

Muchas de las dependencias dependen a su vez de otras librerías, por lo que Maven añadirá de forma transitiva nuevas librerías a nuestro proyecto. En estos casos no necesitamos definir estas nuevas dependencias transitivas en nuestro pom.xml. Como ejemplo, supongamos que un proyecto depende de estas librerías:

• xalan-2-6.0.jar
• xercesImpl
• xml-apis

Al buscar la librería xalan-2-6.0.jar, observamos que la librería depende a su vez de las otras dos librerías. Por ello, para este ejemplo bastaría con declarar la dependencia a xalan-2-6.0.jar en nuestro pom.xml. 

• Conflictos entre librerías

En ocasiones nos podemos encontrar con que dos librerías tengan en sus dependencias a una misma tercera librería, pero de distinta versión. Ello haría que maven incluyese en nuestro Classpath 2 versiones de una misma librería, originando conflictos por duplicado de clases. En ese caso debe declararse en la dependencia de una de ellas una directiva para excluir la descarga de la librería conflictiva.

Por ejemplo, en un proyecto deseamos utilizar la librería siguiente:

<artifactId>jaxws-api</artifactId>
<groupId>javax.xml.ws</groupId>
<version>2.1-1</version>

Y tenemos dependencia a com.sun.xml.ws / jaxws-rt, esta librería se trae como dependencia transitiva otra versión de la librería mencionada anteriormente. Declaramos una exclusión para evitarlo:

<dependency>
  <groupId>com.sun.xml.ws</groupId>
  <artifactId>jaxws-rt</artifactId>
  <version>2.1.4</version>
  <exclusions>
    <exclusion>
      <artifactId>jaxws-api</artifactId>
      <groupId>javax.xml.ws</groupId>
    </exclusion>
  </exclusions>
</dependency>

• Tenemos una librería que se encuentra en los repositorios, pero no hemos podido averiguar el número de versión.

En esta situación, si la librería no parece problemática, podríamos optar por elegir la última versión de la dependencia. En el caso de que consideremos que la versión que utiliza el proyecto puede originar problemas, lo mejor es añadir esta librería manualmente a nuestro repositorio (como si fuese una librería específica del proyecto), según se explica en el próximo punto.

• La librería es específica del proyecto.

En estos casos tendremos que subir la dependencia a nuestro repositorio de librerías y, para evitar conflictos posteriores, se recomienda que sea subida con el mismo groupId de nuestro proyecto. Supongamos que migrando un proyecto nos topamos con librería example1.jar que no se encuentra en ningún repositorio público. En este caso la subimos a nuestro repositorio por ejemplo con la siguiente definición:

<dependency>
    <groupId>com.viavansi.examples</groupId>
    <artifactId>example1</artifactId>
    <version>0.0.1</version>
</dependency>

En la siguiente figura vemos cómo desplegamos una librería a Artifactory:

Comprobación de dependencias

Una vez que hayamos finalizado este proceso de definición de todas las dependencias en nuestro pom.xml, ejecutaremos en consola mvn dependency:tree (situados en el directorio donde se encuentre el fichero pom.xml del proyecto) para comprobar que las dependencias que se han incorporado al proyecto son las correctas. Este paso de verificación es muy importante en las migraciones de este tipo de proyectos, ya que es muy posible que alguna dependencia transitiva genere problemas. Como ejemplo, podemos observar la siguiente salida en la que comprobamos que no hay dependencias transitivas que entren en conflicto con alguna de nuestras librerías:

[INFO] [dependency:tree]
[INFO] com.viavansi.examples.examples1:war:0.0.1
[INFO] +- junit:junit:jar:3.8.1:test
[INFO] +- javax.servlet.jsp:jsp-api:jar:2.1:provided
[INFO] +- javax.servlet:servlet-api:jar:2.4:provided (scope not updated to compile)
[INFO] +- javax.activation:activation:jar:1.1:compile
[INFO] +- avalon-framework:avalon-framework-impl:jar:4.1.5:compile
[INFO] +- axis:axis-ant:jar:1.2.1:compile
[INFO] +- axis:axis:jar:1.2.1:compile
[INFO] +- javax.mail:mail:jar:1.3.1:compile
[INFO] +- commons-beanutils:commons-beanutils:jar:1.6:compile
[INFO] +- commons-codec:commons-codec:jar:1.3:compile
[INFO] +- commons-collections:commons-collections:jar:3.2:compile
[INFO] +- commons-dbcp:commons-dbcp:jar:1.2.2:compile
[INFO] +- commons-digester:commons-digester:jar:1.6:compile
[INFO] |  - xml-apis:xml-apis:jar:1.0.b2:compile
[INFO] +- commons-discovery:commons-discovery:jar:0.2:compile
[INFO] +- commons-httpclient:commons-httpclient:jar:3.1:compile
[INFO] +- commons-io:commons-io:jar:1.3.1:compile
[INFO] +- commons-lang:commons-lang:jar:2.2:compile
[INFO] +- commons-logging:commons-logging:jar:1.1:compile
[INFO] |  +- logkit:logkit:jar:1.0.1:compile
[INFO] |  - avalon-framework:avalon-framework:jar:4.1.3:compile
[INFO] +- commons-pool:commons-pool:jar:1.3:compile
[INFO] +- displaytag:displaytag:jar:1.1:compile
[INFO] +- displaytag:displaytag-export-poi:jar:1.1:compile
[INFO] +- dom4j:dom4j:jar:1.6.1:compile
[INFO] +- org.extremecomponents:extremecomponents:jar:1.0.1:compile
[INFO] +- com.lowagie:itext:jar:1.4.8:compile
[INFO] +- oro:oro:jar:2.0.7:compile
[INFO] +- javax.xml:jaxrpc-api:jar:1.1:compile
[INFO] +- javax.servlet:jstl:jar:1.1.2:compile
[INFO] +- log4j:log4j:jar:1.2.8:compile
[INFO] +- com.oracle:ojdbc14:jar:9.0.2.0.0:compile
[INFO] +- poi:poi:jar:2.5.1-final-20040804:compile
[INFO] +- javax.xml.soap:saaj-api:jar:1.2:compile
[INFO] +- org.springframework:spring:jar:2.0.5:compile
[INFO] +- taglibs:standard:jar:1.1.2:compile
[INFO] +- struts:struts:jar:1.2.9:compile
[INFO] |  +- commons-fileupload:commons-fileupload:jar:1.0:compile
[INFO] |  +- commons-validator:commons-validator:jar:1.1.4:compile
[INFO] |  - antlr:antlr:jar:2.7.2:compile
[INFO] +- wsdl4j:wsdl4j:jar:1.5.1:compile
[INFO] +- wss4j:wss4j:jar:1.5.0:compile
[INFO] +- xalan:xalan:jar:2.6.0:compile
[INFO] +- org.apache.xmlgraphics:xmlgraphics-commons:jar:1.2:compile
[INFO] +- xml-security:xmlsec:jar:1.2.1:compile
[INFO] +- org.directwebremoting:dwr:jar:2.0.3:compile
[INFO] +- com.viavansi:plantilla-client:jar:0.0.13:compile
[INFO] +- net.sourceforge.barbecue:barbecue:jar:1.5-beta1:compile

En caso de detectar librerías duplicadas a causa de las dependencias transitivas, deberemos proceder a definir las exclusiones necesarias en las dependencias afectadas, según se indicó anteriormente.