> On 5 Nov 2015, at 20:07, Marcelo Vanzin <van...@cloudera.com> wrote: > > Man that command is slow. Anyway, it seems guava 16 is being brought > transitively by curator 2.6.0 which should have been overridden by the > explicit dependency on curator 2.4.0, but apparently, as Steve > mentioned, sbt/ivy decided to break things, so I'll be adding some > exclusions. >
It's not that ivy is bad per-se, only that it has a different policy, one which holds *provided all later versions of JARs are backwards compatible* Maven's closest-first policy has a different flaw, namely that its not always obvious why a guava 14.0 that is two hops of transitiveness should take priority over a 16.0 version three hops away. Especially when that 0.14 version should have come If you look at the the diffs for the hive 1.2.1 update patch, the final week was pretty much frittered away trying to get the two builds to have consistent versions of things. 1. I should have historical commit rights to ivy, so, transitively to SBT's dependency logic. If someone writes a resolver with the same behaviour as maven2 I'll see about getting it in. 2. Hadoop 2.6 is on curator 2.7.1; HADOOP-11492. To verify it worked against guava 11.02, I ended up compiling curator against that version to see what broke. curator-x-discovery is the only module which doesn't compile against older guava versions (HADOOP-11102) -Steve --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@spark.apache.org For additional commands, e-mail: dev-h...@spark.apache.org
