CODEWITHSUNDEEP
javabuildplayframeworksbtplayframework-2.3
jcreason
jcreason

Reputation: 857

How to exclude directory from source in an SBT Play Framework 2.3 project

I have multiple Play Framework 2.3.8 projects that share a common set of models and other library files from a different repository. This other "shared" repo is symlinked into the app directories of each of the projects during development, and copied there before deploy.

I want to have all of the unit tests associated with this set of shared libraries in the shared repo, so that they get executed regardless of which project they're being compiled in. However, because these files are all then buried in the app directory, which is defined as sources by default in build.sbt, the project won't compile because the package is defined from the viewpoint of the test directory.

The structure roughly looks like this:

app/
  controllers/
  shared -> ../../shared
test/
  shared -> ../app/shared/test

Is there a way in my build.sbt to tell it to ignore the test directory inside of app/shared? Or, if someone has a better suggestion for how to structure this, any ideas are welcome. Thanks!

Upvotes: 2

Views: 1960

Answers (2)

James Roper
James Roper

Reputation: 12850

To answer your first question, of excluding test:

excludeFilter in (Compile, unmanagedSources) := {
  val testDir = ((sourceDirectory in Compile).value / "shared" / "test").getCanonicalPath
  HidderFileFilter | SimpleFileFilter(_.getCanonicalPath.startsWith(testDir))
}

To answer your second question, a better way to structure this is to use project refs:

lazy val shared = ProjectRef(file("../shared"), "shared-name")

lazy val myProject = (project in file(".")).dependsOn(shared)

In this setup, ../shared is a stand alone build with it's own build.sbt that you can publish etc, and shared-name is the name (set by name := "shared-name" of the project in that build).

An even better way would be to have the shared project be the root project, and myProject (and other projects that depend on it) be sub projects in the same build.

Upvotes: 2

Aaron Digulla
Aaron Digulla

Reputation: 328624

My solutions for problems like this is to define a "unit test JAR", i.e. a JAR that is like junit.jar in that you can add it to your project as test dependency and that it contains support code for tests.

To use the support code, you need to write a test which extends the unit test support code or kicks off some kind of runner that runs the test in the support JAR.

Upvotes: 1

Related Questions