ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Garrison <>
Subject RE: Ivy and Maven Repository with nth-level transitive dependencies in POMs
Date Fri, 18 Sep 2009 19:36:20 GMT
> -----Original Message-----
> From: Geoff Clitheroe []
> Sent: Friday, September 18, 2009 1:14 PM
> To:
> Subject: Re: Ivy and Maven Repository with nth-level transitive
> dependencies in POMs
> Hi Jim,
> Ivy will use Maven repos (e.g.,
> and fetch transitive
> dependencies without any additional work (it will read the POMS).
> We've been using it like this with great success.  You will run into
> Maven projects with bad or incorrect POM specs and have to fix them or
> work around them but this tends to be older projects.  Ivy roundup is
> worth a look if this becomes a problem
> Also, some projects may have dependencies in the 'wrong' configuration
> and need a manual exclude:
> <dependency org="org.apache.activemq" name="activemq-pool" rev="5.2.0"
> conf="provided->default">
>     		<exclude module="spring-beans"></exclude>
>     	</dependency>
> There are also some things you just can't get from a repo (e.g., some
> DB drivers).  We run our own 'manual' repo for this with hand rolled
> skeleton ivy files.  If you're already using Nexus and caching locally
> then you're well advanced anyway.

OK, I got that to work, but there's something fundamental I still don't get.  When I give
activemq as a dependency, Ivy retrieves huge gobs of stuff I know isn't needed just to use
activemq, such as jetty, derby and  geronimo.  

If I set usepoms="false" in ivysettings.xml it fetches only activemq.jar, but that defeats
the purpose of Ivy and relegates it to a simple jar-fetcher.

There's a bigger issue here, what used to be called "DLL Hell" in Windows.  We depend on 40
or so OSS packages, many of which have common dependencies on other packages.  In some cases,
two first-level dependencies will need different versions of the same transitive dependency,
which Java doesn't handle at all (without custom classloaders - yuck).  Keeping things working
seems like it will require manually specifying the version of just about everything -- finding
that one version of, say, log4j et al that works with everything else we need. 

Or, am I missing something here?

View raw message