Download as PDF, PPTX
![HOW SBT WORKS
TASKS 'VS PLUGINS
Appear directly in build definition file, shared via VCS
Task can be turned into plugin and shared via repository
val gitHeadCommitSHA = taskKey[String]("Determines the current git comm
it SHA")
gitHeadComitSHA := Process("git rev-parse HEAD").lines.head](https://image.slidesharecdn.com/sbtcrashcourse-130913004707-phpapp02/75/SBT-Crash-Course-10-2048.jpg)
![CORE CONCEPTS
SETTINGS, TAKE TWO
Settings are typesafe => every key has only one type and any
value placed into setting must match exact type
Grouping of SettingKey[T]with Initialize[T]
creates Setting[T]
name := "big-project"
| |
SettingKey[String] Initialize[String]](https://image.slidesharecdn.com/sbtcrashcourse-130913004707-phpapp02/75/SBT-Crash-Course-20-2048.jpg)
![CORE CONCEPTS
SETTINGS, TAKE FOUR
Initializations are a Scala expressions that can produce value
of desired type
Intializations may use other settings via setting.value
method.
version := "1.0"
libraryDependencies += ("org.scalatest" %% "scalatest" % version.value)
| |
SetingKey[ModuleID] Initialization[ModuleId]
/
Setting[ModuleID]](https://image.slidesharecdn.com/sbtcrashcourse-130913004707-phpapp02/75/SBT-Crash-Course-22-2048.jpg)
![CORE CONCEPTS
CUSTOM TASKS AND SETTINGS
For version 0.12.4 have to be defined in Scala file not sbt
one
From 0.13.0 they can be defined in sbt too
val gitHeadCommitSHA = taskKey[String]("Determines the current git
commit SHA")
|
setting/task definition
gitHeadComitSHA := Process("git rev-parse HEAD").lines.head
| |
setting/task key block of code returning value](https://image.slidesharecdn.com/sbtcrashcourse-130913004707-phpapp02/75/SBT-Crash-Course-25-2048.jpg)
![CORE CONCEPTS
CUSTOM TASKS AND SETTINGS
For version 0.12.4 have to be defined in Scala file not sbt
one
From 0.13.0 they can be defined in sbt too
val gitHeadCommitSHA = taskKey[String]("Determines the current git
commit SHA")
|
setting/task definition
gitHeadComitSHA := Process("git rev-parse HEAD").lines.head
| |
setting/task key block of code returning value](https://image.slidesharecdn.com/sbtcrashcourse-130913004707-phpapp02/75/SBT-Crash-Course-27-2048.jpg)
Uploaded byMichal Bigos
SBT Crash Course
The document provides a comprehensive overview of sbt (Simple Build Tool), highlighting its advantages, core concepts, and functionalities. It contrasts sbt with older build tools like Apache Ant and Maven, explaining how sbt facilitates task-based parallel execution and easier dependency management. Key topics include the structure of sbt projects, configuration settings, multi-module builds, and custom tasks, showcasing its compatibility with both Java and Scala.
More Related Content
![[Image Results] Java Build Tools: Part 2 - A Decision Maker's Guide Compariso...](https://cdn.slidesharecdn.com/ss_thumbnails/java-build-tools-part-2-maven-gradle-ant-ivy-140121040954-phpapp01-thumbnail.jpg?width=640&height=640&fit=bounds)
SBT Crash Course
- 1. SBT CRASH COURSEBy/Michal Bigos @teliatko
- 2. SBT CRASH COURSE 1.Why SBT 2. How SBT works 3. Example of simple project 4. Core concepts
- 3. WHY SBT GOOD BUILDTOOL CRITERIA Reproducibility - automating build, gives you more time to do real stuff Conventions - using sensible defaults, no need to specify every last option and command Experience - distilation of developer wisdom, e.g. test before publish Portability - good build tool should protect you from differences betweeen systems Ecosystem - allow to extend build easily
- 4. WHY SBT LITTLE HISTORY:APACHE ANT Former standard build tool for Java projects Pros: 1. Portability - build is defined in XML by chaining tasks 2. Experience - abillity to explicitly define dependencies between tasks Cons: 1. Conventions - no default build lifecycle, each build is piece of art 2. Ecosystem - not easy to extend, task definition distributed as jar
- 5. WHY SBT LITTLE HISTORY:APACHE MAVEN Currently heavily used in enterprise Java projects Most opinionated build tool Pros: 1. Portability - build is defined in XML so called POM 2. Experience, Conventions - Maven introduces default lifecycle with its phases and tasks. It promotes declarative dependency management. Cons: 1. Ecosystem - not easy to extend. Maven plug-in archtecrure requires plug-in written in Java, then POMs and packaging and availability in repository.
- 6. WHY SBT LITTLE HISTORY:GOOD PARTS Default project layout (Maven) Default project behavior (Maven) Declarative dependency management (Maven) Portability (Ant, Maven)
- 7. WHY SBT FEATURES ATGLACE Uses Scala to describe build Can be used for Java and Scala Minimal configuration (inspired by Maven) A number of build-in tasks Declarative dependency management (using Apache Ivy) Portability Reactive development environment Allows use Scala REPL Incremental compilation Automatic re-compilation with different versions of Scala
- 8. HOW SBT WORKS TASKS Taskbased, more like ANT, no phases like in Maven If you want to do something you execute a task If you want to ensure that a task runs after another, add an explicit dependency between the tasks Output of a task is value, which can be of any type and past to any another task Multiple tasks can depend upon the output of the same task By default tasks are executed in parallel Using dependency tree sbt can work out what can be run in parallel or in sequence
- 9. HOW SBT WORKS DEFAULTSTRUCTURE AND LAYOUT Inspired by Maven {project root} project/ build.properties plugins.sbt src/ main/ scala/ java/ resources/ test/ scala/ java/ resources/ target/ build.sbt
- 10. HOW SBT WORKS TASKS'VS PLUGINS Appear directly in build definition file, shared via VCS Task can be turned into plugin and shared via repository val gitHeadCommitSHA = taskKey[String]("Determines the current git comm it SHA") gitHeadComitSHA := Process("git rev-parse HEAD").lines.head
- 11. HOW SBT WORKS PHASES'VS TASK DEPENDENCIES In Maven, the order of execution tasks in phases always leads to confusion Default goals for a phase are executed before explicitly defined and those are executed in implicit order of definition in POM file Implicit order of execution can cause problems when parallelizing build, if there are dependencies between goals SBT is per default parallel, that's why explicit definition of task dependencies is needed It's similar to definition a custom lifecycle in Maven, which is not easy too
- 12. HOW SBT WORKS PARALLELEXECUTION If task A depends on B, and C also depends on B => SBT will run B first and then A and C in parallel
- 13. HOW SBT WORKS PASSINGINFORMATION BETWEEN TASKS In Maven and ANT it's very hard to pass an information between tasks Usually through an intermediate file In SBT, you can simply return the value from the task and use it in another dependent task This makes chaining tasks a lot easier
- 14. HOW SBT WORKS WORKINGWITH SCALA Cross compilation for multiple Scala versions => Scala is binary compatible only between minor version releases Not restricted to Scala versions either scalaVersion := "2.10.1" crossScalaVersions := Seq("2.8.2", "2.9.2") libraryDependencies += (scalaBinaryVersion.value match { case "2.10" => "org.specs2" %% "specs2" % "2.0" case "2.9.1" => "org.specs2" %% "specs2" % "1.12.4" })
- 15. HOW SBT WORKS WORKINGWITH SCALA, TAKE TWO Scala compiler generates lots more classes and JVM takes longer to start-up => interactive environment Scala compilation is slow (in comparision to Java) => incremental compilation Multi-module builds => parallel execution, child modules don't need to know about parent module
- 16. EXAMPLE OF SIMPLEPROJECT A COMMON DEVELOPERS USAGE
- 17. CORE CONCEPTS BUILD FILES build.properties build.sbt Blankline is required between settings project/ build.properties - defines SBT version plugins.sbt - defines SBT plugins build.sbt - defines actual build, project settings sbt.version = 0.12.4 name := "big-project" version := "1.0" scalaVersion := "2.10.0" libraryDependencies += "org.scalatest" %% "scalatest" % "1.9.1" % " test"
- 19. CORE CONCEPTS SETTINGS Mechanism toconfigure a build to to perform th ework we need to SBT reads all the settings defined in build at load time and runs their initializations name := "big-project" | | | key operator intialization
- 20. CORE CONCEPTS SETTINGS, TAKETWO Settings are typesafe => every key has only one type and any value placed into setting must match exact type Grouping of SettingKey[T]with Initialize[T] creates Setting[T] name := "big-project" | | SettingKey[String] Initialize[String]
- 21. CORE CONCEPTS SETTINGS, TAKETHREE Operators used with settings Types have to match name := "big-project" | assignment libraryDependencies += "org.scalatest" %% "scalatest" % "1.9.1" | append append multiple values | libraryDependencies ++= Seq( "org.scalatest" %% "scalatest" % "1.9.1" % "test", "org.specs2" %% "specs2" % "2.0" % "test" )
- 22. CORE CONCEPTS SETTINGS, TAKEFOUR Initializations are a Scala expressions that can produce value of desired type Intializations may use other settings via setting.value method. version := "1.0" libraryDependencies += ("org.scalatest" %% "scalatest" % version.value) | | SetingKey[ModuleID] Initialization[ModuleId] / Setting[ModuleID]
- 23. CORE CONCEPTS DEFINING DEPENDENCIES Definitionof exact version Cross-compiled dependency groupId % artifactId % version % scope groupId %% artifactId % version % scope | Use appropriate scala version from project
- 24. CORE CONCEPTS CIRCULAR REFERENCES BecauseSBT can use values of one setting to instatiate another, it's possible to create circular references Build will fail to load when circular references are detected.
- 25. CORE CONCEPTS CUSTOM TASKSAND SETTINGS For version 0.12.4 have to be defined in Scala file not sbt one From 0.13.0 they can be defined in sbt too val gitHeadCommitSHA = taskKey[String]("Determines the current git commit SHA") | setting/task definition gitHeadComitSHA := Process("git rev-parse HEAD").lines.head | | setting/task key block of code returning value
- 26. Definitions are compiledfirst and can reference another definitions Settings are executed after definitions, hence can refence any definition Tasks are executed every time the value is requested
- 27. CORE CONCEPTS CUSTOM TASKSAND SETTINGS For version 0.12.4 have to be defined in Scala file not sbt one From 0.13.0 they can be defined in sbt too val gitHeadCommitSHA = taskKey[String]("Determines the current git commit SHA") | setting/task definition gitHeadComitSHA := Process("git rev-parse HEAD").lines.head | | setting/task key block of code returning value
- 28. Definitions are compiledfirst and can reference another definitions Settings are executed after definitions, hence can refence any definition Tasks are executed every time the value is requested
- 29. MORE TO COVER 1.Scopes 2. Multi-module projects 3. Basic SBT objects in Scala
- 30. THANKS FOR YOURATTENTION