Apologies if this is a duplicate -- my original post never showed up on the 
list.

> -----Original Message-----
> From: Geoff Clitheroe [mailto:[email protected]]
> Sent: Friday, September 18, 2009 1:14 PM
> To: [email protected]
> Subject: Re: Ivy and Maven Repository with nth-level transitive 
> dependencies in POMs
> 
> Hi Jim,
> 
> Ivy will use Maven repos (e.g.,
> http://mirrors.ibiblio.org/pub/mirrors/maven2/) 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 
> http://code.google.com/p/ivyroundup/
> 
> 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?

Reply via email to