sbt

warning: Creating default object from empty value in /opt/bitnami/apps/portal/htdocs/modules/taxonomy/taxonomy.pages.inc on line 33.

sequencing tasks with sbt-sequential

in

In this post, I will discuss the execution semantics and task sequencing in sbt 0.13. First we will cover the background, and then I will introduce a new experimental plugin sbt-sequential that adds sequential tasks.

background

Mark said:

The sbt model is to have your side effects be local to your task so that as long as dependencies are satisfied, the task can be executed whenever. The win is parallel by default and enabling faster builds in practice.

In other words, with sbt, the build definitions only define the dependencies between the tasks. The timing at which these tasks are triggered is automatically calculated by sbt. To understand this, we should first look at the execution semantics of a Scala code with side effects.

traveling through the 4th dimension with sbt 0.13

in

Warning: This is a memo about sbt for intermediate users.

setting system

At the heart of sbt 0.13 is the setting system, just like sbt 0.12. Let's look at Settings.scala:

trait Init[Scope] {
  ...
 
  final case class ScopedKey[T](
    scope: Scope,
    key: AttributeKey[T]) extends KeyedInitialize[T] {
    ...
  }
 
  sealed trait Initialize[T] {
    def dependencies: Seq[ScopedKey[_]]
    def evaluate(map: Settings[Scope]): T
    ...
  }
 
  sealed class Setting[T] private[Init](
    val key: ScopedKey[T], 
    val init: Initialize[T], 
    val pos: SourcePosition) extends SettingsDefinition {
    ...
  }
}

If we ignore pos for now, a setting of T consists of the lhs key whose type is ScopedKey[T], and the rhs init whose type is Initialize[T].

sbt-logo proposal

in


.sbt build definition

sbt plugins roundup

in

Unlike XML-based build tools sbt's build definitions are written in Scala (for both .sbt and .scala). This means that once one gets over the hurdle of learning sbt's concepts and operators, it doesn't take much for build users to start writing sbt plugins.

I've ported a few from sbt 0.7 before, but I've also been writing some original ones recently that I'd like to share.

an unofficial guide to sbt 0.10 v2.0

in

don't panic

If you've just landed from 0.7 world, sbt 0.10 is overwhelming. Take your time to understand the concepts, and I assure you that you'll get it in time, and really love it.

three representations

There are three ways you may interact with sbt 0.10, which could be confusing at first.

  1. shell, which you get when you start sbt 0.10.
  2. Quick Configuration DSL, which goes into build.sbt or in settings sequence.
  3. good old Scala code, aka Full Configuration.

testing sbt plugins

in

NOTE: Official docs: http://www.scala-sbt.org/1.x/docs/Testing-sbt-plugins.html

Let's talk about testing. Once you write a plugin, it turns into a long-term thing. To keep adding new features (or to keep fixing bugs), writing tests makes sense. But how does one go about testing a plugin to a build tool? We fly, of course.

scripted test framework

Syndicate content