cunei
commented
10 years ago I looked into this matter a bit more. There is no way, within sbt, to discriminate whether a given project name was user-defined or if it was created by sbt as a "default project"; @harrah confirmed it a while back. Since the same name can be either a regular project, or a default project name, and there is no way to tell them apart, for the time being it doesn't seem that any heuristic improvement is possible. The caveat (which only occurs in rare cases) will therefore just have to be documented as such. The necessary information ("is this project a default project?") might possibly be added as a flag in a future version of sbt, however.
The dbuild logic uses some heuristics that is aimed at recognizing when an sbt subproject name really corresponds to the "default projects" (this is a source of recurring troubles in sbt as well). Among the possible variations on the name, a subproject with the same name as the containing directory is currently also interpreted as the default project (0.13 only); that assumption breaks with some projects (for instance specs2) that use the same string for one of their own (really defined) subprojects. This is only a problem when using dbuild-setup, as during compilation dbuild deliberately uses directories based on hashes, to avoid this specific issue. A workaround is just renaming the clone dir prior to using dbuild-setup; however, this should be documented as a caveat, and a more sophisticated heuristic should eventually be put in place.