Unresolved dependencies - problem resolving the right versions of dependencies

[sriramkrishnan]

Hi,

I am playing around with dbuild for a couple of Twitter OSS projects - Storehaus (https://github.com/twitter/storehaus) and Summingbird (https://github.com/twitter/summingbird).

My dbuild keeps failing trying to resolve dependencies, with errors of this form - basically it is looking for _algebird-core2.10.5, when I expect it to look for _algebird-core2.10:

[storehaus] sbt.ResolveException: unresolved dependency: com.twitter#algebird-core_2.10.5;0.10.2: not found

The dependency is here: https://github.com/sriramkrishnan/storehaus/blob/develop/project/Build.scala#L157

It builds fine with sbt, as you can see from the public Travis builds - https://travis-ci.org/twitter/storehaus

What am I doing wrong? I am hoping that I am missing some options, since I am a dbuild n00b. Thanks in advance.

And here is my dbuild file:

build.extraction-version: "2.10"
build.cross-version: disabled

build: {
  sbt-version: "0.13.5"
  projects: [
  {
    name:   storehaus
    system: sbt
    uri:    "git://github.com/sriramkrishnan/storehaus#dbuild"
    check-missing: false
  }, {
    name:   summingbird
    system: sbt
    uri:    "git://github.com/sriramkrishnan/summingbird#dbuild"
    check-missing: false
  }
 ]
}

[cunei]

Hello!

In this case you will need:

build.cross-version: standard

That will cause all the dependencies that do not refer to projects in the config file to remain unchanged.

In short, the main application of dbuild is that of testing a "closed-world" system of dependencies, in which all the dependencies are fully specified, from the compiler to all of the dependent libraries. Those dependencies can be specified either in source form, in which case dbuild will recompile them, or by referring to already published artifacts with a fixed version (by resolving them using Ivy or, since v0.9.3-M3, using Maven). This mode of operation is particularly useful, for instance, when testing the Scala compiler itself during development: the compiler and a large set of community libraries are tested each night to make sure that they all work together. In order to refer to the specific version of Scala that is being tested, by default the full Scala binary version is used in the dependencies, rather than just "_2.11".

By using "standard" for the "cross-version" option, this default behavior is removed, and the usual Scala binary version will apply. In this case, dbuild will no longer try to refer to fixed versions of everything, and the closed world assumption is removed. Some additional details are also available in the online manual, at the page: http://typesafehub.github.io/dbuild/0.9.2/buildOptions.html

Incidentally, the line:

build.extraction-version: "2.10"

should probably be something like "2.10.4". This option informs dbuild that the specified version of Scala should be used in order to detect the set of dependencies of each project. The specified Scala compiler is not actually invoked; what happens is that: 1) "scalaVersion" is set to that value, then 2) sbt is asked for the resulting set of project dependencies. That helps while detecting the dependencies of those projects that may include a different set of dependencies depending on which version of the Scala compiler is used (for instance, some only on 2.10.x, and some others only on 2.11.x). In your case, sbt will use the (non-existent) version "2.10" of Scala, which in general will work, but on some libraries might not.

Hope this helps!

[sriramkrishnan]

Thanks for the explanation @cunei! Sorry it took me a while to get back to this, but your suggestion does fix the original problem. It doesn't quite work just yet for me, but not because of this issue. I am going to go ahead and close this.