I have a set of loosely related components where some of these depend on others. For concreteness, lets assume we have components "common", "a" and "b". "common" does not have any dependencies, but all other projects use "common". Furthermore, "a" depends on "b". All components are written in Scala, and I would like to use sbt to build them.
The following properties would be nice to have:
- Multiple people work on the different projects, which is why we don't want to have a single repository, but rather one repository per project.
- Building a project should be easy, and all dependencies should be build automatically (if necessary). That is, if I modify "common" and then build "b", this should first build "common" and then go on to build "b".
- Be able to have all projects in an IDE, such that refactoring and similar IDE-tasks work correctly and all affected projects are changed correctly.
As far as I can see, there are two possibilities to have dependencies of this kind in sbt; either we use sub-projects, or use a managed dependency (that is pushed somewhere, e.g., locally). However, it seems that both of these options don't provide either (1) or (2) above. In particular
- Using sub-projects forces us to use a single repository, because all sub-project must be in sub-directories of the main project.
- Publishing the projects locally and using managed dependencies is cumbersome, as changing "common" and then building "b" only picks up the changes in "common" if that project was build and published first. I can see that managed dependencies are useful for many cases, but for our particular use-case they don't seem to work well. We frequently work on several projects and change them at the same time. For this reason, having to publish often seems overly complicated.
Is there really no way to say that an sbt project depends on another sbt project at a certain (relative) location, and having sbt figure out when to build the dependency?