addPlugins does not work when used in a build.sbt file located in a subdirectory

[julienrf]

I have the following structure:

root/
+- project-a/
    +- build.sbt
+- project-b/
    +- build.sbt
+- build.sbt

The root/build.sbt file just aggregates the sub projects:

lazy val `project-a` = project

lazy val `project-b` = project

And, in both root/project-a/build.sbt and root/project-b/build.sbt I use addPlugins:

lazy val root = project.in(file(".")).addPlugins(Foo)

If I run sbt from the root/ directory the sub-projects are loaded but they behave is if the addPlugins were missing.

If I run sbt from the root/project-a/ or root/project-b/ directory everything works as expected.

[jsuereth]

This is a fundamental limitation in our loading system right now. We do not merge "instances of the project class" so the first one we see wins, in this case the one defined in root/build.sbt. The current workaround is to define the addPlugins in that build.sbt file.

[jsuereth]

Also, sbt should be detecting this. Which version of sbt are you using? In 0.13.5-M4 I see:

java.lang.RuntimeException: Overlapping output directories:/home/jsuereth/projects/sbt/diagnose/auto-plugin-issue/project-a/target:
    ProjectRef(file:/home/jsuereth/projects/sbt/diagnose/auto-plugin-issue/,root)
    ProjectRef(file:/home/jsuereth/projects/sbt/diagnose/auto-plugin-issue/,project-a)

[jsuereth]

Oh, also one final thing: WIth sbt-multi-project you need always run from the root directory. Sbt does not support the maven-style mechanism of cd-ing into a subdirectory and building. Internal to the sbt console you can swap the active-project via the project command.

[julienrf]

Yeah, I’m using 0.13.5-M2.

WIth sbt-multi-project you need always run from the root directory

I’d like to! So, by adding the addPlugins thing in the root build.sbt file it is ok. But, since my root project does nothing more than aggregating the subprojects I hoped it was also possible to also run the projects from their directories… I use the root project only to run the tests of both sub-projects.

[jsuereth]

So, you should see: #1213 . We plan to resolve this issue and that one at the same time.

Basically, inside the lower build.sbt you'll be able to do manipulations to the project object inline, like:

enablePlugins(Web)

configs(Foo)

libraryDependencies ++= Seq(...)

So, the Project.* methods become available for .sbt files directly and apply to the project located in the same directory as the directory the .sbt file resides.

This requires restructuring how sbt loads files so that we can capture these functions and redoing the ordering of loads so we can apply these methods appropriately. Therefore, that work has been delayed until 0.13.6.

If you have any concerns/questions, would love to hear them!

[jsuereth]

It's implemented, but still needs run through the ringer.

Just a note for myself: 52e3e6f

[jsuereth]

Oh, also this still doesn't do project merging. we could after this improvement, but I'm not sure that's healthy for us right now until we get rid of some public APIs that shouldn't be public.

For now, this just allows enablePlugins directly in an sbt file.

[jsuereth]

So i'm going to close this for now. We're not sure we'll ever do the "merge project instances" thing between different .sbt/.scala files, but you should be able to declare the plugins in the sub-.sbt file and just reference the project from the master build.scala/build.sbt.