Triggered Execution

You can make an action run when certain files change by prefixing the action with ~. The files that are monitored for changes are defined by the watchPaths method of the current project and the projects it depends on. By default, a project watches resources and Scala and Java sources. Monitoring is terminated by default when enter is pressed. This can be changed by overriding the terminateWatch method for the current project.

Some example usages are described below.


The original use-case was continuous compilation, and you can still use cc to use it. cc is now equivalent to

> ~ test-compile

If you only want to recompile main sources, you can do

> ~ compile


You can use the triggered execution feature to run any action or method. One use is for test driven development, as suggested by Erick on the mailing list.

The following will poll for changes to your source code (main or test) and run test-quick on affected tests.

> ~ test-quick
The test-quick method only runs tests that either have not succeeded yet (that is, tests that failed or haven't been run yet) or were recompiled. A test is recompiled if any of its transitive dependencies changed, so this is one way to automatically run tests potentially affected by changes to the code.

If you find that the test-quick method runs too many tests, you might use the test-failed method instead.

> ~ test-failed
The test-failed method only runs tests that have not succeeded (that is, tests that failed or haven't been run yet). It does not rerun tests just because they were recompiled, unlike the test-quick method.

There is another level of control, which is to explicitly filter the tests to run. All of the test-* commands for running tests use the explicit filter methods available in the project defintion for use with the standard test action (the ExcludeTests and TestFilter test options and the includeTest method). However, you can additionally restrict the tests to run by specifying the tests to include as arguments to the test-quick or test-failed methods. Also, if you don't want the additional functionality of test-quick or test-failed, there is the test-only method, which always runs the tests passed as arguments even if the test previously succeeded and was not recompiled.

> ~ test-quick example.MySpecification
On source changes, this will rerun example.MySpecification if it had to be recompiled (because it or a dependency changed) or if it had not successfully run. It will not rerun other tests, even if they had to be recompiled or have not successfully run.
> ~ test-only example.MySpecification
On source changes, this will always rerun example.MySpecification.

Web Applications

If you use jetty-run, you can automatically build and reload your web application on changes to your source:

> jetty-run
> ~ prepare-webapp

This will first start Jetty and then trigger execution of the action that builds the web application provided to Jetty. The jetty-run action will pick up changes and redeploy. See the WebApplications page for details on configuring jetty-run, including configuring redeployment.