Вот пример build.sbt
:
import AssemblyKeys._
assemblySettings
buildInfoSettings
net.virtualvoid.sbt.graph.Plugin.graphSettings
name := "scala-app-template"
version := "0.1"
scalaVersion := "2.9.3"
val FunnyRuntime = config("funnyruntime") extend(Compile)
libraryDependencies += "org.spark-project" %% "spark-core" % "0.7.3" % "provided"
sourceGenerators in Compile <+= buildInfo
buildInfoPackage := "com.psnively"
buildInfoKeys := Seq[BuildInfoKey](name, version, scalaVersion, target)
assembleArtifact in packageScala := false
val root = project.in(file(".")).
configs(FunnyRuntime).
settings(inConfig(FunnyRuntime)(Classpaths.configSettings ++ baseAssemblySettings ++ Seq(
libraryDependencies += "org.spark-project" %% "spark-core" % "0.7.3" % "funnyruntime"
)): _*)
Цель состоит в том, чтобы иметь искровое ядро "provided"
, чтобы он и его зависимости не включались в артефакт сборки, а чтобы повторно включать их в путь пути выполнения для задач run
- и test
.
Похоже, что использование настраиваемой области в конечном итоге будет полезно, но я не согласен с тем, как фактически заставить задачи по умолчанию/глобальному запуску/тестированию использовать пользовательский libraryDependencies
и, надеюсь, переопределить значение по умолчанию. Я пробовал вещи, включая:
(run in Global) := (run in FunnyRuntime)
и т.п. безрезультатно.
Подводя итог: это, по сути, является обобщением веб-случая, когда servlet-api находится в "предоставленной" области, а задачи запуска/тестирования обычно вызывают контейнер сервлетов, который действительно обеспечивает сервлет-api для выполняемого кода, Единственное различие здесь в том, что я не откатываю отдельную JVM/среду; Я просто хочу вручную увеличить пути к классам этих задач, эффективно "отменить" "предоставленную" область действия, но таким образом, чтобы продолжать исключать зависимость от артефакта сборки.