Menu
When building a plugin for sbt 0.13, is it important which version of scala 2.10 any library dependencies (of the plugin) are built against?
Currently my plugin is dependent upon libraries built against scala 2.10.2. This works fine for single builds, but when a build (A) is dependent upon another build (B), via ProjectRef, I find that the sbt compile of the build directive in project B fails. It seems to be that sbt is using 2.10.2 to build the directive files, but that scala-reflect-2.10.0.jar is being loaded (from the sbt debug traceback, after Calling Scala compiler with arguments (CompilerInterface) is printed to screen).
If I build the referenced project (B) on its own, the build of the directives file succeeds but looking again at the jars being loaded I see that scala-2.10.2/lib/scala-reflect.jar is referenced instead.
The error message on failure is:
[error] error while loading MacroValue, Missing dependency 'bad symbolic reference. A signature in MacroValue.class refers to term annotations
[error] in package scala.reflect.internal which is not available.
[error] It may be completely missing from the current classpath, or the version on
[error] the classpath might be incompatible with the version used when compiling MacroValue.class.', required by /home/alex.wilson/.ivy2/cache/org.scala-sbt/main-settings/jars/main-settings-0.13.0.jar(sbt/std/MacroValue.class)
[error] error while loading InputEvaluated, Missing dependency 'bad symbolic reference. A signature in InputEvaluated.class refers to term annotations
[error] in package scala.reflect.internal which is not available.
[error] It may be completely missing from the current classpath, or the version on
[error] the classpath might be incompatible with the version used when compiling InputEvaluated.class.', required by /home/alex.wilson/.ivy2/cache/org.scala-sbt/main-settings/jars/main-settings-0.13.0.jar(sbt/std/InputEvaluated.class)
[error] error while loading ParserInput, Missing dependency 'bad symbolic reference. A signature in ParserInput.class refers to term annotations
[error] in package scala.reflect.internal which is not available.
[error] It may be completely missing from the current classpath, or the version on
[error] the classpath might be incompatible with the version used when compiling ParserInput.class.', required by /home/alex.wilson/.ivy2/cache/org.scala-sbt/main-settings/jars/main-settings-0.13.0.jar(sbt/std/ParserInput.class)
[error] three errors found
I can rebuild my plugin so that it is dependent upon libraries built against 2.10.0 if required. But I'm not sure if that is the correct approach and going to help. Any advice would be greatly appreciated.
240
sbt uses that same version of Scala to compile the build definitions that you write for your project because they use sbt APIs. This version of Scala is fixed for a specific sbt release and cannot be changed. For sbt 1.7. 1, this version is Scala 2.12.
Background. update resolves dependencies according to the settings in a build file, such as libraryDependencies and resolvers . Other tasks use the output of update (an UpdateReport ) to form various classpaths. Tasks that in turn use these classpaths, such as compile or run , thus indirectly depend on update .
Having said that, at the very beginning, sbt will always download its own internal dependencies, Scala including. It is then saved in ~/.
sbt (through Ivy) verifies the checksums of downloaded files by default. It also publishes checksums of artifacts by default. The checksums to use are specified by the checksums setting.
sbt 0.13.0 requires Scala 2.10.2 or later. The error message indicates a missing class that was introduced in 2.10.2. So, the classpath appears to include an older Scala version, as you mention. Generally, if you don't set the scalaVersion, the correct version of Scala should be included on classpaths for sbt plugins.
132
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
