CODEWITHSUNDEEP
sbt
Yann Simon
Yann Simon

Reputation: 458

converting a .scala project definition using Project.configs to build.sbt

I am trying to convert a build definition from Scala to build.sbt

In the Scala definition, I have something like:

  lazy val ComponentTest = config("componenttest") extend Test
  val componentTests = inConfig(ComponentTest)(Defaults.testTasks) ++ Seq(
    testOptions in ComponentTest := Seq(Tests.Filter(componentTestFilter))
  )

  val main = play.Project(appName, appVersion, appDependencies ++ testDependencies)
    .settings(...)
    .configs(ComponentTest)
    .settings(componentTests: _*)

  private def componentTestFilter(name: String): Boolean = name endsWith "CT"

I have not found out how to migrate the Project.configs(ComponentTest) to a build.sbt

The only solution I found was much more complex:

lazy val ComponentTest = config("componenttest") extend Test

inConfig(ComponentTest)(Defaults.testSettings)

javaSource in ComponentTest := (javaSource in Test).value

scalaSource in ComponentTest := (scalaSource in Test).value

configuration in ComponentTest := (configuration in Test).value

testOptions in ComponentTest := (testOptions in Test).value

testOptions in Test += Tests.Filter(unitFilter)

testOptions in ComponentTest := Seq(Tests.Filter(componentTestFilter))

def componentTestFilter(name: String): Boolean = name endsWith "CT"

Defining all settings again (javaSource, scalaSource...) does not feel right.

Is there something better? Or should I mix .scala and .sbt definitions? Or stick to .scala?

Upvotes: 0

Views: 64

Answers (1)

lpiepiora
lpiepiora

Reputation: 13749

You can refer to your project using project macro.

lazy val main = project.in(file(".")).configs(ComponentTest)

lazy val ComponentTest = config("componenttest") extend Test

inConfig(ComponentTest)(Defaults.testTasks) ++ Seq(
  testOptions in ComponentTest := Seq(Tests.Filter(componentTestFilter))
)

def componentTestFilter(name: String): Boolean = name endsWith "CT"

As for your question if you should mix both .scala and .sbt. I think it's a valid approach when needed. The build.sbt has it's limitations, e.g. code in different .sbt files is not shared, and writing complex builds is inconvenient (you have to remember to add extra line after each statement and to keep all expressions together).

I would say you should stick to whatever suits you.

Upvotes: 3

Related Questions