3

I am trying to enable forking in sbt for test task only, which excluding the rests of test command (test-only, test:compile, etc).

At first I thought the solution would be:

fork in test := true

But then I saw on the documentation, doing that will enable forking all test tasks which is not what I want.

I also found out there is Test variable (has uppercase first letter). What is the difference between test and Test?

Then I also saw another example:

fork in (Test, run) := true

which sbt manual said it's for forking test:run and test:runMain:. At first I thought (Test, run) means test:run, but seeing another example below, it seems the meaning is not like that: 

// sets the working directory for `run` and `runMain` only
baseDirectory in (Compile,run) := file("/path/to/working/directory/")

So there are variables with capital first letter (e.g. Test, Compile, Runtime), and variables with lowercase first letter (e.g. test, testOnly, compile, console, run), the latter seems corresponds to sbt commands, but I'm not clear about the former. So what's the difference between them?

null
  • 8,669
  • 16
  • 68
  • 98
  • Maybe not what you are asking, but there is this setting you might want to look at. Run `inspect test:testOnly::testForkedParallel`. – marios Aug 12 '16 at 22:53

1 Answers1

2

Generic background

sbt has three scope axis (think of it as a 3D space) for all its variables (keys). Alternatively, you can think of it as 3-tired namespaces.

1) Project, 2) Configuration, and 3) Task

From sbt interactive: 

<project-id>/config:intask::key

So you can say execute from project X (D-1) and configuration Compile (D-2) the run task (D-3). This will execute the main function found in the compile (under main/src folder) code of project X. 

sbt> projectX/compile:run

Similarly you can say execute run in the Test configuration of project X. This will now execute the main method (say you have one defined) that is under the test/src folder. 

sbt> projectX/test:run

Now, tasks also have keys (internal configuration variables). For example: 

sbt> show projectX/compile:compile::sources

This will show the source files used by the compile task of Project-X's Compile configuration (when you compile just your code, not the tests). 

sbt> show projectX/test:compile::sources

This will show the source files used by the compile task of Project-X's Test configuration (when you compile just your test files).

Naming in SBT DSL

sbt has different convention for naming tasks and scopes while you are writing in its DSL (inside .sbt files) and while executing tasks interactively via the sbt cli. 

projectX/test:compile::sources

translates to 

sources in (Test,compile) in projectX

So to get to your question. Test with capital T is the configuration scope. Similar Compile with capital C is the configuration scope. The lowercase compile, test etc are your tasks.

Now, sbt has a lot of default scopes. For example, if you just enter sbt and type compile, it will actually execute the compile task under the Compile configuration of the Root project.

marios
  • 8,874
  • 3
  • 38
  • 62
  • is single word command like `compile` will be automatically translated to twin words `compile:compile` ? – null Aug 13 '16 at 00:21
  • exactly, sbt will default to running compile in the compile scope. So compile and compile:compile are in general synonymous. On the other had, test:compile will run compile in the Test scope and essentially compile your tests. Did the question help in any way? I can try to modify a bit to make it more informative. – marios Aug 13 '16 at 01:16
  • This answer might also be useful for you: http://stackoverflow.com/q/18289766/1553233 – marios Aug 13 '16 at 01:19
  • Honestly I have a bit difficulty to understand your explanation. So the `test` is equal to `test:test` but excluding `test-only, test:compile`, etc ? And `Test` is equal to any test related tasks (`test:*` and `test*`) ? – null Aug 13 '16 at 02:36
  • Capital Test is not a task. This is a so called configuration. A namespace used to group together all the keys (tasks, settings, commands, etc) that have to do with a particular core activity (Compile, Test, Runtime). You can also create your own configurations, like IntegrationTest or DockerDeployment or anything else you want to have custom family of settings (libraries, dependencies, java settings, etc etc). – marios Aug 13 '16 at 04:02
  • So if I want to enable forking only for `test` task, but excluding the other testing tasks (test-only, test:compile, test:compile), how to do that? – null Aug 13 '16 at 13:20
  • 1
    `fork in test := true` it should only enable forking when you execute the `test` task. It should not do it on test:compile unless you do `fork in (Test,compile) := true`. If you want to change the setting in testOnly then do `fork in (Test,testOnly) := false`. – marios Aug 14 '16 at 00:56