sbt 最简单的带输入任务 inputTask

在 sbt 中我们可以定义 settingKey, taskKey 和 inputKey. inputKey 接收输入的任务更具灵活性,虽然在 sbt 中 taskKey 和  inputKey 数量比例为 25:1,但仍然不可忽视了 inputKey 的贡献。

起初在阅读 sbt 关于 inputKey 的资料时,一不小心就被带入到 Parser 上去了。其实还不如开门见山,先跳过 Parser 部份,示范 inputKey 任务中直接处理用户的原生输入。

这里有两个最简单的 sbt inputKey 的示例

一. 命令后非空格起全部输入当作一个字符串

trimmed() 方法能去除了两边的空格,如果是 token(any.* map(_.mkString)).parse 则两边空格都会算上,在 demo1 abc  的 abc 两边的空格也都会算在输入参数里

> demo1 abc "abc"
abc "abc"


sbt  的  input task  参数居然默认是紧接着命令开始的,如上面如果输入是 demo1xxx, demo1 任务接收到的参数是 xxx. 如果同时也定义了另一个任务是 demo1x, 那么输入 demo1xx 就会执行 demo1x 任务,参数是 xx. 从后往前进行匹配任务名。这个还有点奇怪,因为我以前任何时候都是自然的把命令与参数用空格分开,它却可以把命令与参数写在一起。

 


二. 像调用 main 方法一样传入参数

阅读全文 >>

sbt 任务间的依赖

项目中的 build.sbt 中发现定义任务时有 task2 <<= task1 map {...} 这样任务依赖的写法, 这个  <<= 方法有点晦涩难懂, 读过 sbt in action 之后才知道这是 sbt 0.12 或之前的做法, sbt 0.13 之后不这么用了, 直接访问下 task1.value 就行, 因此前面可改写为 task2 := {task1.value; ...}, 这也使得定义任务依赖时与普通任务一致风格了. 新的写法得益于 Scala 2.10 的宏特性, 后面还会讲到.

对于依赖于多个任务的情况, 在 sbt 0.13 前面分别是这样的, 假定有三个 Task(task1, task2, 和 task3)

val task1 = taskKey[Int]("task 1")
val task2 = taskKey[Int]("task 2")
val task3 = taskKey[Int]("task 3")

如果 task3 依赖于 task1 和 task 2

sbt 0.13 前后版本中的写法分别是

像任务的 .value 属性其实是一个宏定义, 源码 阅读全文 >>

sbt 中单元测试并发执行

此次研究的目的原本是要使得 Play Framwork 2 中单元测试能够并发执行, 包括 JUnit 和 Spec 的测试用例, Play 2 的 activator 就是一个 sbt 的包装. 开发中发现我们 Play 2 中的单元测试是按序执行的, 实际上 sbt 下测试用例默认是并发执行的. 之所以 Play 2 的单元测试是按序的, 是因为 activator 设置了把 sbt 的两个属性 fork in Test := trueparallelExecution in Test := false, 见 PlaySettings.scala, 它们默认分别为 false 和 true. 这使得默认设置下 Play 2 中的所有测试无法并发执行.

sbt 默认的 fork 是 false, Play 2 改为 true 之后便可以使用 javaOptions in Test := "-Dkey1=value1" (注: 如果 fork 为 false 的话, javaOptions 将无效.) 往单元测试中参数了, 这也是为什么在 Play 2 的单元测试中无法获得启动 sbt 时(像 sbt -Dkey1=value) 的参数, 不同一个 JVM 啊.

那是不把 Play 2 的 fork in TestparallelExecution in Test 分别改回成 false 和 true 就可以让测试用例并发执行了呢? 答案是 Yes. 但我们得相信 Play 2 把它们预设为 true 和 false 是有它的用意的, 比如集成测试的每个用例都会开启本地的 3333 端口, 如果让两个集成测试同时执行将会造成端口冲突. 细致说来, Play 2 其实是懒政, 只管一刀切而让所有测试按序执行而影响了效率, 如能利用好 sbt 的测试分组机制是可以达到测试的并发执行的.

这里引出 sbt 执行测试的几个机制:

1) sbt 总是对测试进行分组, 默认时所有的测试都包含在 <default> 组中, 可用 show testGrouping 查看, 如

阅读全文 >>

查看 sbt 项目的依赖关系树

sbt 是借助于 ivy 来管理项目依赖, 像 Maven 项目中可以用 dependency:tree 来显示依赖树, 那么对于 sbt 项目该如何查看项目依赖关系呢? 本文提及了三种方式来显示项目依赖, 它们是 Shell 脚本, 自定义 sbt 任务, 和 sbt-dependency-plugin 方式. 最后一个办法使得我们也能用 dependencyTree 显示出 Maven 的  dependency:tree 效果来, 还有更酷的的.

> dependencyTree
[info] default:test_2.10:0.1-SNAPSHOT [S]
[info]   +-ch.qos.logback:logback-classic:1.0.13
[info]     +-ch.qos.logback:logback-core:1.0.13
[info]     +-org.slf4j:slf4j-api:1.7.5
[info]
[success] Total time: 0 s, completed Apr 5, 2016 12:29:53 AM

下面是探索的全部过程.

通过 sbt 控制台的 tab  自动完成或用 help .*[Dd]ependenc.* 命令再进一步过滤出与依赖比较接近 sbt 控制台任务 阅读全文 >>

Java 构建工具及 sbt 最快速体验

应对 Java 项目, 我们大概有以下几个自动化构建工具:

  1. Ant -- XML 化跨平台批处理, 配置文件 build.xml, 执行的是 target
  2. Maven -- 开始标准化目录布局, 基于项目对象模型, 配置文件 pom.xml, 执行的是 phase/goal
  3. Gradle  -- 使用 Maven 默认布局, Groove 语言铸就, 配置是 groovy 语法的 build.gradle 文件, 执行的是 task
  4. Buildr  -- 默认也是 Maven 目录布局, Java 世界被 Ruby 插手, 配置是 ruby 语法的 buildfile 文件, 也是 task
  5. Leiningen -- 也采用 Maven 目录布局, Clojure 写的, 可用于构建 Java 和 Clojure 项目, 配置文件是 Clojure 语法的 prject.clj, 基于 task
  6. sbt  -- 默认 Maven 目录布局, Scala(Simple) Build Tool, Scala 写的, 构建 Java 和 Scala 项目, 配置是 Scala 语法的 build.sbt, 基于 task. 交互式控制台.

Ant 让我们摆脱了对系统平台的依赖, 终于不同人构建的工件是一样的了, 曾经它就是昭示着敏捷. 除了 Ant 需要我们定义所有的 target 外, 其他构建都内置了基本足够用的 task, 而且也都采用了业界接受的 Maven 目录布局. 也是从 Maven 开始引入了项目依赖管理, 所以 Maven 才是里程碑式的.

在我们搜索 Java 第三方依赖时常常进到类似这样的页面 http://mvnrepository.com/artifact/com.google.guava/guava/19.0

java-dependencies 阅读全文 >>

sbt 项目通过 sbt-aspectj-plugin 使用 AspectJ

Java 在运用面向方向编程时,依照  AspectJ 的语法自己书写 *.aj 文件可以得到尽可能大的控制能力。如果是一个 sbt 的项目,有一个 sbt-aspectj-plugin 插件可以帮上我们的忙。那么如何应用这个插件呢? 该插件首页面告诉我们要在 project/plugins.sbt 中加上下面这句话

其他就是参考例子 runnable sample projects,然而这几个例子并非那么直白。所以还是自己做一个最简单的例子来体验 sbt 项目如何使用 AspectJ. 阅读全文 >>

sbt 中自定义的 Task

sbt, 又是一种自动化构建工具,意为 Simple Build Tool,目前还难副其名,它管理依赖也是用的 Ivy。Scala 相关的项目一般会用它,如 Play2,所以需要来研究下它怎么自定义任务。

sbt 项目可以用 build.sbt 或 project/Build.scala 来定义项目,build.sbt 里写些简单的 settings 表达式,而 Build.scala 就强大,可以写 val, object 和方法定义。而且单个 Build.scala 可以定义多个项目,build.sbt 只用来定义当前项目。build.sbt 和 project/Build.scala 能同时存在,它们的内容会编译到一块。还有一个全局的 build.sbt 文件 ~/.sbt/build.sbt,这里控制所有的项目。

所以我们分别看在 project/Build.scala 和 build.sbt 中如何定义自己的 task

首先看 project/Build.scala,分别由两行完成

val mytask = taskKey[Unit]("This is my customized task")
mytask := { println("Execute customized task")}

完整的一个 project/Build.scala 如下 阅读全文 >>

使用 sbt 的 np 插件自动创建目录结构和 build.sbt 文件

通常我们要创建一个 sbt 项目需要经历以下几步:

$ mkdir testscala && cd testscala      #创建项目目录 testscala,并进入该目录
testscala $  mkdir -p src/{main,test}/scala   #创建源文件目录结构,可能还需要 mkdir -p src/{main,test}/resources
$ vi build.sbt # 填入基本的信息 (name, organization, version)
$ sbt

这一看怎么这么复杂啊,特别是习惯了 Maven 的同学们更会这么觉得。Maven 不仅可应用各种模板来创建不同类型的工程,完整的工程目录结构都有了。

那么 sbt 能不能做到自动创建目录和配置文件呢,答案是: 本身不能。你可以基于一个项目模板目录结构拷来拷去。前面说是 sbt 本身不能,要知道 sbt 是一个插件化更彻底的玩意,如今的 0.12.2 的 sbt.zip 才 1M 大小,其余全赖插件帮你插来插去了。

因此,我们找来的 np(New Project) 插件 https://github.com/softprops/np 帮我们创建工程的目录结构和 build.sbt 文件。它能让我们创建项目的过程简化为以下两步操作:

$ mkdir testscala && cd testscala   #这一步还是不能少
$ sbt
> np name:testscala org:cc.unmi   #这样 testscala 下 {main.test}/{scala,resources} 和  build.sbt 文件都有了

np 的安装及使用可以参考:https://github.com/softprops/np,就是下面的步骤: 阅读全文 >>