2

我正在维护一些与此双层解决方法类似的代码：

import AssemblyKeys._   
lazy val assemblySettings: Seq[sbt.Project.Setting[_]] = baseAssemblySettings

implicit def wrapTaskKey[T](key: TaskKey[T]): WrappedTaskKey[T] = WrappedTaskKey(key) 
case class WrappedTaskKey[A](key: TaskKey[A]) {
  def orr[T >: A](rhs: Initialize[Task[T]]): Initialize[Task[T]] =
    (key.? zipWith rhs)( (x,y) => (x :^: y :^: KNil) map Scoped.hf2( _ getOrElse _ ))
}

lazy val baseAssemblySettings: Seq[sbt.Project.Setting[_]] = Seq(
  test <<= test orr (test in Test).identity,
  test in assembly <<= (test in Test).identity,
)

（从这里）。

我应该如何完全删除此解决方法的两个“层”，因为在 sbt >= 0.12 中显然不再需要它们？

4

2 回答 2

2

我什至不确定 or 仍然是必要的。

不再需要了。

或者

or是在 sbt 0.10 中工作的#202（任务范围键）的解决方法。但根据评论，这已在 sbt 0.12 中修复。让我们在 sbt 0.13 中测试一下：

helloworld> set test in Compile in compile := {}
[info] Defining helloworld/compile:compile::test
helloworld> inspect test
[info] Task: Unit
[info] Description:
[info]  Executes all tests.
[info] Provided by:
[info]  {file:/Users/eed3si9n/work/helloworld/}helloworld/test:test
....

所以我们很清楚#202。事实上，我or上周（2013 年 9 月 28 日）为 0.10.0 从 sbt-assembly 中重新布线，现在看起来像这样：

// test
test in assembly := (test in Test).value,

或

这orr是#204 ("Reference to undefined setting" while using an optional key)的一种解决方法，它or在 sbt 0.11.0 中中断，并根据标签在 0.11.1 中修复。由于我们不再需要or，这有点争议，但orr在 sbt 0.11.1 之后我们不需要了。

为避免进一步混淆，我从非官方指南中删除了该部分并链接到 github 以获取历史兴趣。

于 2013-10-05T03:54:34.017 回答
0

查看 sbt-assembly 的日志，在那里所做的只是删除wrapTaskKey和WrappedTaskKey替换orr.or

我不确定即使or仍然有必要。但我根本不明白这段代码。

于 2013-10-02T16:59:23.247 回答