I think there are a few minor differences in the dependency graph that arise from this. For a given user, the probability it affects them is low - it needs to conflict with a library a user application is using. However the probability it affects *some users* is very high and we do see small changes crop up fairly frequently.
My feeling is mostly pragmatic... if we can get things working to standardize on Maven-style resolution by upgrading SBT, let's do it. If that's not tenable, we can evaluate alternatives. - Patrick On Fri, Nov 6, 2015 at 3:07 PM, Marcelo Vanzin <van...@cloudera.com> wrote: > On Fri, Nov 6, 2015 at 3:04 PM, Koert Kuipers <ko...@tresata.com> wrote: > > if i understand it correctly it would cause compatibility breaks for > > applications on top of spark, because those applications use the exact > same > > current resolution logic (so basically they are maven apps), and the > change > > would make them inconsistent? > > I think Patrick said it could cause compatibility breaks because > switching to sbt's version resolution means Spark's dependency tree > would change. Just to cite the recent example, you'd get Guava 16 > instead of 14 (let's ignore that Guava is currently mostly shaded in > Spark), so if your app depended transitively on Guava and used APIs > from 14 that are not on 16, it would break. > > -- > Marcelo >
