if there is no strong preference for one dependencies policy over another, but consistency between the 2 systems is desired, then i believe maven can be made to behave like ivy pretty easily with a setting in the pom
On Fri, Nov 6, 2015 at 5:21 AM, Steve Loughran <ste...@hortonworks.com> wrote: > > > 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 > >
