Reputation: 13716
A question about composing sbt projects:
I forked a library project (https://github.com/allenai/pipeline) and wish to hack on it vis-a-vis my project that uses it. If I put them in the same multi-project build ― really my preferred option over publishing locally and consuming ― sbt will not read the project
dir of the nested fork (where .scala
files and plugin definitions originally reside).
E.g. I try, in build.sbt:
lazy val pipeline = (project in file("pipeline"))
lazy val githubCruncher = (project in file("."))
.dependsOn(pipeline)
And I get errors indicating directory pipeline/project
is being ignored; the build.sbt
itself of the nested project is being read, but sbt does not find what is defined alongside to it in its sibling project
directory (and hence fails to load build definition).
So, must I squash the two projects into a single build.sbt
or can I somehow elegantly compose the two without that? I am asking because this has also been a problem on other projects I work on where I ended up squashing each and every build definition minutia into one big monolith ― even though I'd prefer distributing some of the sub-projects as independent projects aside my own dev configuration.
Upvotes: 1
Views: 71
Reputation: 13716
According to my experience looks like everything inside the project
directory of a project being pulled into a multi-project build ― needs to move to project
under the root of the multi-project build, whereas the build.sbt
of the pulled-in project does not have to be squashed ― a reference to it from from the top level build.sbt
will work (unless that reference is followed by definitions for it right there in the top level build.sbt
).
Sbt plugins coming from the pulled-in project then become applied to the unified multi-project build, and need to be disabled with disablePlugins
for other sub-projects, if or where appropriate or desireable.
Upvotes: 1