-
2 comentarios »
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></pre>Sencillo, ¿no?.
2 comentarios para “Dependencias molestas en Maven”
Deja un comentario
- We need a great designer
- Hablar por hablar, ese deporte
- Retos para el 2010 en Linking Paths
- Sobre los premios Buber, las críticas y la acción.
- Manifiesto: En defensa de los derechos fundamentales en Internet
- Consumidos por la reinvención
- ¿Quién es tu cliente?
- El factor psicológico
- Lanzamiento: Stage
- ¡Hola Competencia! Te estábamos esperando.
RSS de los últimos artículos
- JM. en Hablar por hablar, ese deporteLoose talk, the sport
(2 comentarios) - zp en Hablar por hablar, ese deporteLoose talk, the sport
(2 comentarios) - alberto en Retos para el 2010 en Linking PathsChallenges for 2010
(8 comentarios) - Raúl Murciano en Retos para el 2010 en Linking PathsChallenges for 2010
(8 comentarios) - Javier Aldana en Retos para el 2010 en Linking PathsChallenges for 2010
(8 comentarios) - alberto en Retos para el 2010 en Linking PathsChallenges for 2010
(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 [...]