oh ok i think i got it... i hope! since the app runs with the spark assembly jar on its classpath, the exact version as resolved by spark's build process is actually on the apps classpath.
sorry didnt mean the pollute this thread with my own dependency resolution confusion. On Fri, Nov 6, 2015 at 6: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 >
