Its not included, it is downloaded on demand. That said I think the fact that we can download the jar is a huge feature of SBT, no installation needed, build the project as long as you have a JVM.
On Fri, Nov 6, 2015 at 4:49 PM, Jakob Odersky <joder...@gmail.com> wrote: > > Can you clarify which sbt jar (by path) ? > Any of them. > Sbt is a build tool, and I don't understand why it is included in a source > repository. It would be like including make in a project. > > On 6 November 2015 at 16:43, Ted Yu <yuzhih...@gmail.com> wrote: > >> bq. include an sbt jar in the source repo >> >> Can you clarify which sbt jar (by path) ? >> >> I tried 'git log' on the following files but didn't see commit history: >> >> ./build/sbt-launch-0.13.7.jar >> ./build/zinc-0.3.5.3/lib/sbt-interface.jar >> ./sbt/sbt-launch-0.13.2.jar >> ./sbt/sbt-launch-0.13.5.jar >> >> On Fri, Nov 6, 2015 at 4:25 PM, Jakob Odersky <joder...@gmail.com> wrote: >> >>> [Reposting to the list again, I really should double-check that >>> reply-to-all button] >>> >>> in the mean-time, as a light Friday-afternoon patch I was thinking about >>> splitting the ~600loc-single-build sbt file into something more manageable >>> like the Akka build (without changing any dependencies or settings). I know >>> its pretty trivial and not very important, but it might make things easier >>> to add/refactor in the future. >>> >>> Also, why do we include an sbt jar in the source repo, especially if it >>> is used only as an internal development tool? >>> >>> On 6 November 2015 at 15:29, Patrick Wendell <pwend...@gmail.com> wrote: >>> >>>> 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 >>>>> >>>> >>>> >>> >> >
