Sbt-assembly unresolved dependency, Scala
Asked Answered
E

4

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)
Ectropion answered 22/9, 2015 at 15:3 Comment(0)
F
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.

Formulaic answered 22/9, 2015 at 17:3 Comment(5)
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.Diatonic
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).Formulaic
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)Diatonic
No, meta-build with wrong scalaVersion shouldn't be able to build the build definition at all (at least I think so).Formulaic
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.Diatonic
O
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.

Onassis answered 18/8, 2016 at 14:10 Comment(0)
D
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")

Dissyllable answered 10/11, 2017 at 18:51 Comment(0)
L
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

Lankton answered 12/1, 2018 at 10:39 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.