sbt

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

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

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

sbt comes with scripted test framework, which let's you script a build scenario. It was written to test sbt itself on complex scenarios such as change detection and partial compilation:

Syndicate content