14

I'm installing Sbt-Assembly, but am now stuck. 

Sbt Version (from 'sbt about'): 0.13.8
Current project is built against scala 2.11.6
Sbt, sbt plugins, and build definitions are using Scala 2.10.4

project/assembly.sbt

   addSbtPlugin("com.eed3si9n" % "sbt-assembly" % "0.14.0")
   resolvers += Resolver.url("bintray-sbt-plugins", url("http://dl.bintray.com/sbt/sbt-plugin-releases"))(Resolver.ivyStylePatterns)

build.sbt

   scalaVersion in ThisBuild := "2.11.6"

~/.sbt/0.13/global.sbt

   scalaVersion := "2.11.6"

I realize sbt-assembly is for scala 2.10. If I change my project to scala 2.10, I have new unavailable dependencies for 2.10 which is not desirable. Is there a way to configure my project to use 2.10 just for the assembly plugin? 

  ==== bintray-sbt-plugins: tried
  http://dl.bintray.com/sbt/sbt-plugin-releases/com.eed3si9n/sbt-assembly/scala_2.11/sbt_0.13/0.14.0/ivys/ivy.xml

  ::::::::::::::::::::::::::::::::::::::::::::::
  ::          UNRESOLVED DEPENDENCIES         ::
  ::::::::::::::::::::::::::::::::::::::::::::::
  :: com.eed3si9n#sbt-assembly;0.14.0: not found
  ::::::::::::::::::::::::::::::::::::::::::::::

  Note: Some unresolved dependencies have extra attributes.  
  Check that these dependencies exist with the requested attributes.

      com.eed3si9n:sbt-assembly:0.14.0 (scalaVersion=2.11, sbtVersion=0.13)
user2827214
  • 1,191
  • 1
  • 13
  • 32

4 Answers4

10

Just remove scalaVersion from global.sbt.

Because SBT is recursive it uses this scalaVersion from global.sbt when building your build files, which fails because SBT 0.13 is built with Scala 2.10, and so are all SBT plugins.

Alexey Romanov
  • 167,066
  • 35
  • 309
  • 487
  • This is a very annoying, especially since SBT doesn't look to be built against Scala 2.11+ any time soon (n years later). I'm not entirely clear why defining the version of Scala you want to use for artifacts built by the meta-build should define the version sbt needs to run that build. Doubly annoying because this is *not* clear in the documentation. – Nathaniel Ford Aug 12 '16 at 21:35
  • It's the other way around: the meta-build needs to use SBT libraries. Scala 2.11 is going to be used in SBT 1.0 (unsurprisingly, it can't be changed in a minor release). – Alexey Romanov Aug 13 '16 at 06:01
  • It was easy enough to see that SBT 1.0 would use Scala 2.11: but the timeline is still undefined, and this is a pain point. I am curious though: I thought the reason I ran into trouble was that my meta-build built a proper-build definition on the `scalaVersion` it had specified, and my proper-build couldn't run because SBT wasn't aligned with that? Once I stopped specifying a version in my meta-build, my proper-build worked (assuming I hard-coded library dependencies in my meta-build). (I've been wrestling for a week on this. :P) – Nathaniel Ford Aug 13 '16 at 06:07
  • No, meta-build with wrong `scalaVersion` shouldn't be able to build the build definition at all (at least I think so). – Alexey Romanov Aug 13 '16 at 06:14
  • Huhn. I think what I was seeing was that the build definition was built but died because it had confused attributes when looking up a library dependency. But this is probably the wrong place to discuss it. – Nathaniel Ford Aug 13 '16 at 06:16
4

I had a similar problem, what helped was adding addSbtPlugin("com.eed3si9n" % "sbt-assembly" % "0.14.3") to the project/plugins.sbt instead of plugins.sbt in the root directory of my project.

wmiel
  • 153
  • 5
2

I had a similar error. Changing sbt-assembly version (from 0.14.3 to 0.14.5) worked. My sbt version was 1.0.3 and I used : addSbtPlugin("com.eed3si9n" % "sbt-assembly" % "0.14.5")

Debajyoti Pathak
  • 104
  • 6
1

Just don't use sbt-assembly at all! :) Flat-jars cause conflicts during merging which need to be resolved with assemblyMergeStrategy. Use the binary distribution format plugin that sbt offers which enables you to distribute in binary script, dmg, msi and tar.gz.

Check out sbt-native-packager

kosiara - Bartosz Kosarzycki
  • 10,922
  • 12
  • 70
  • 83