-
Uno de las grandes ventajas de Maven puede ser uno de sus grandes problemas: las dependencias transitivas. Esto es, si en maven yo digo que necesito, digamos el API de MyFaces, él solito se encargará de bajar todas las librerías que necesita MyFaces. Esto que es un gran avance, puede ser molesto si la persona que ha preparado MyFaces (o cualquier otro proyecto, hablo de MyFaces sólo como ejemplo) no ha tenido en cuenta que dependencias son reales y cuales no.
Dentro de Maven se pueden declarar dependencias de cinco tipos, tal y como se explica en la propia documentación (aquí concretamente). El problema viene si usamos una librería cuyo autor ha declarado todas las dependencias como compile, normalmente por comodidad. ¿Qué podría ocurrir por ejemplo en el caso de Hibernate?. Para compilar el proyecto, necesitaremos un montón de librerías que luego no nos harán falta en tiempo de ejecución, por ejemplo sólo nos hará falta una de sus implementaciones de pool de conexiones o de caché. Si el autor pusiera todas esas dependencias en modo compile nuestro proyecto incluiría TODOS esos jar. Demasiados.
Pero más aún. Supongamos que ese proyecto incluye un API desfasado, o que choca con otras versiones que tengamos, o con nuestro servidor de aplicaciones. Por ejemplo supongamos que un proyecto incluye una dependencia a un API de XML desfasado que impide que Tomcat vuelva a arrancar. Es sólo un suponer. ¿Como puedo eliminarlo sin perder la ayuda de las dependencias transitivas?.
Afortunadamente la gente que escribió Maven ya ha pensado en eso, y al declarar una dependencia podemos eliminar de nuestro proyecto una de estas dependencias transitivas. La forma de hacerlo sería la siguiente:
myfaces myfaces-api <version>1.1.0</version> <scope>compile</scope> <exclusions> <exclusion> <artifactId>xml-apis</artifactId> <groupId>xml-apis</groupId> </exclusion> </exclusions> </dependency>
Sencillo, ¿no?.
2 comentarios para “Dependencias molestas en Maven”
Deja un comentario
- Hay días que parece que la meta se aleja según te acercas
- Diseña primero, codifica después.
- La Rumble 2009 calienta motores
- One ticket to Euruko 2009 can be yours
- Días duros, días buenos
- Conciliación
- EuRuKo 2009
- Diseño industrial
- Innovación.. Qu’est-ce que c’est?
- Euskadi, el software libre y otras cosas que estan de moda.
RSS de los últimos artículos
- Dani Latorre en Hay días que parece que la meta se aleja según te acercas
(4 comentarios) - alberto en Hay días que parece que la meta se aleja según te acercas
(4 comentarios) - Ricardo en Hay días que parece que la meta se aleja según te acercas
(4 comentarios) - Álvaro Sánchez-Mariscal en Hay días que parece que la meta se aleja según te acercas
(4 comentarios) - Ricardo en Diseña primero, codifica después.
(8 comentarios) - ana en Diseña primero, codifica después.
(8 comentarios)
RSS de los últimos comentarios
-
Sobre LinkedLinked es el blog de Linking Paths, la empresa aventurera e innovadora formada por Aitor Garcia, Alberto Molpeceres y Roberto Salicio. En él hablamos de nuestros productos, ideas, y de compañías que nos sirven como guía y ejemplo. Si quieres conocernos un poco mejor puedes revisar lo que hemos escrito en los archivos.
-
Proyectos, ideas, etc.





Chupao ;-)
Es uno de esos problemas de que JDK 1.5 tenga parser de xml.
[...] transitivas. ¿Quién no se ha peleado con las dependencias transitivas? Hoy por hoy la situación está más controlada por existen [...]