i was compiling my scalafx code in intellij in a sbt file and they kept showing me this error, please help i tried everything but its still not working
[info] Updating
[info] Resolved dependencies
[warn]
[warn] Note: Unresolved dependencies path:
[error] stack trace is suppressed; run last update for the full output
[error] (update) sbt.librarymanagement.ResolveException: Error downloading org.scalafx:scalafx_2.13:8.0.192-R14
[error] Not found
[error] Not found
[error] not found: /Users/xxxxx/.ivy2/local/org.scalafx/scalafx_2.13/8.0.192-R14/ivys/ivy.xml
[error] not found: https://repo1.maven.org/maven2/org/scalafx/scalafx_2.13/8.0.192-R14/scalafx_2.13-8.0.192-R14.pom
this is my built.sbt
name := "practical4b"
version := "0.1"
scalaVersion := "2.13.1"
// https://mvnrepository.com/artifact/org.scalafx/scalafx
libraryDependencies += "org.scalafx"%%"scalafx"%"8.0.192-R14"
The problem here is that there is no release of ScalaFX 8/R14 that works with Scala 2.13.
Each Scala release, with the exception of bug-fix releases, has different binary compatibility requirements. So if you're using a Scala-built library with, say, Scala 2.13, you need the build of that library created for the same Scala version. Libraries created from Java code typically have binary compatibility with any version of Scala.
To determine which Scala versions are supported, they are listed in the column under Scala on Maven Central (the site linked to in your code above the libraryDependencies property):
You can resolve this problem either by switching to Scala 2.12, by changing the Scala version as follows:
scalaVersion := "2.12.12"
Or, you can use a more recent version of ScalaFX, that will work with Scala 2.13, by changing the library dependency as follows:
libraryDependencies += "org.scalafx" %% "scalafx" % "12.0.2-R18"
to use R18, or:
libraryDependencies += "org.scalafx" %% "scalafx" % "14-R19"
for R19.
A lot will depend upon which version of Java you are using. If you need to use Scala 2.13, with one of the more recent ScalaFX releases, I would recommend using Java 11 LTS. If you must use Java 8, then stay with the ScalaFX 8/R14 release and use Scala 2.12. Let me know if you have any questions.
Related
When I try to run ( through SBT) my scala program I run into a bunch of errors.
Here's an excerpt:
[error] missing or invalid dependency detected while loading class file 'IterableUtils.class'.
[error] Could not access type ScalaObject in package scala,
[error] because it (or its dependencies) are missing. Check your build definition for
[error] missing or conflicting dependencies. (Re-run with `-Ylog-classpath` to see the problematic classpath.)
[error] A full rebuild may help if 'IterableUtils.class' was compiled against an incompatible version of scala.
[error] missing or invalid dependency detected while loading class file 'AsBooleanTrait.class'.
[error] Could not access type ScalaObject in package scala,
[error] because it (or its dependencies) are missing. Check your build definition for
[error] missing or conflicting dependencies. (Re-run with `-Ylog-classpath` to see the problematic classpath.)
.....
I did add the scala-library.jar to the classpath but to no avail. Does anyone know what might be missing?
Ps. used -> new SBT project (Intellij) on osx
edit: here's the build.sbt
name := "test"
version := "1.0"
scalaVersion := "2.11.8"
resolvers += "Scales XML" at "https://mvnrepository.com/artifact/org.scalesxml/scales-xml_2.9.1"
libraryDependencies += "org.scalesxml" % "scales-xml_2.9.1" % "0.3-RC7"
SBT is version 0.13.8
Edit 2:
Figured it out. I was trying to run a class (with a main method) without creating an instance... After changing it to an Object things work a lot better :)
Edit 3:
Spoke too soon. I turns out it has to do with setting the scalaVersion in build.sbt. When I leave that entire line out, it no longer complains about the missing dependencies. When I put it back in I get the errors mentioned above back. I tried setting it to 2.11.7 as well ( after installing that with brew install scala) but to no avail.
scalaVersion := "2.11.8"
libraryDependencies += "org.scalesxml" % "scales-xml_2.9.1" % "0.3-RC7"
You can't use a library compiled for Scala 2.9.1 with Scala 2.11.*. Write "org.scalesxml" %% "scales-xml" % some-version instead, which will look for scales-xml_2.11. See http://www.scala-sbt.org/0.13/docs/Cross-Build.html.
I'm experiencing a problem when running latest play framework 2.3.
It compiles just fine, although when I do activator run this error happens:
java.lang.NoSuchMethodError: scala.Predef$.ArrowAssoc(Ljava/lang/Object;)Ljava/lang/Object;
Full error log
I explicitly tried scalaVersion in every build.sbt file and it is the same.
I tried several things like activator clean, full removal os sbt caches and local repo sbt stuff, updating dependencies to latest version but no success.
I have scala version defined.
My current dependencies are:
I tried with both %% and force _2.11 in the name of the dependency.
Dependency List
Other important files
build.sbt
Common.scala
Dependencies.scala
When I fully clean caches it downloads scala 2.10.4 for no reason:
in this download log it says the sbt need the old scala.
Any idea why is this?
Any ideas?
Firstly, it does not matter which version of Scala is used to generate your build. The build system can use version 2.10.4, and that does not prevent your code from using version 2.11.1.
To look at the issue with your scala version, you should consider that settings added directly in build.sbt are added to the root project, but not to other projects. You can see this with a minimal project such as:
$ cat build.sbt
scalaVersion := "2.11.1"
lazy val subproj = project in (file("subproj"))
Then the output of sbt looks like this:
> show scalaVersion
[info] subproj/*:scalaVersion
[info] 2.10.4
[info] sbttest/*:scalaVersion
[info] 2.11.1
So, how can this be fixed?
We can create a lazy val containing a Seq[Setting[_]], and add it to the sub-project definition with the settings() method.
Here's an example build.sbt which adds the same settings to all projects:
$ cat build.sbt
lazy val root = project.in(file("."))
.aggregate(subproj)
.dependsOn(subproj)
.settings(commonSettings: _*)
lazy val subproj = project.in(file("subproj"))
.settings(commonSettings: _*)
lazy val commonSettings = Seq(
scalaVersion := "2.11.1"
)
The _* is required because settings() is defined as requiring Setting[_]* rather than Seq[Setting[_]], so _* converts between the two types. See also: What does param: _* mean in Scala?
And the output from sbt is:
> show scalaVersion
[info] subproj/*:scalaVersion
[info] 2.11.1
[info] root/*:scalaVersion
[info] 2.11.1
This approach can easily be applied to your build.
You're defining your dependencies in the wrong way.
When using SBT, don't use:
"org.mydep" % "mydep_2.11" % "1.0.0"
Instead use:
"org.mydep" %% "mydep" % "1.0.0"
The %% operator automatically appends the current Scala version of the current build. If you use dependencies built against other Scala versions, you're going to be getting the weird errors.
Also make sure you explicitly specify your Scala version somewhere:
scalaVersion := "2.11.1"
The problem was related to some manually added jars that I discovered in the lib folder, that were causing issues with the dependencies of the project defined in the build.sbt.
The only way to find out was to generate a activator dist and look for similar dependencies with different versions since in the dependency graph there were no conflicts
I want to add a Java library (e.g. Apache PDFBox) to an sbt project.
This is the Ivy dependency:
dependency org="org.apache.pdfbox" name="pdfbox" rev="1.8.2"
I first tried to do the following:
resolvers += "Sonatype releases" at "http://oss.sonatype.org/content/repositories/releases/"
libraryDependencies += "org.apache.pdfbox" %% "pdfbox" % "1.8.2"
But it gives me errors of the type
[warn] ==== public: tried [warn]
http://repo1.maven.org/maven2/org/apache/pdfbox/pdfbox_2.10/1.8.2/pdfbox_2.10-1.8.2.pom
So I understand that with this syntax I can just manage Scala dependencies. I am sure that there is a way to manage Java dependencies, but how?
I tried to search in Google for "sbt add java dependencies" but did not find (recognize) a relevant result.
You should replace the %% (double percent) with single one.
libraryDependencies += "org.apache.pdfbox" % "pdfbox" % "1.8.2"
The double-percent is a convenience operator, and causes adding the _+scalaVersion postfix inside the path, which is _2.10 in your case. Single percent should fix the problem.
Short answer:
Use
libraryDependencies += "org.apache.pdfbox" % "pdfbox" % "1.8.2"
For java libraries, and
libraryDependencies += "org.scalactic" %% "scalactic" % "3.0.8"
For Scala libraries, where the difference is the double % for the scala library.
Long answer:
Scala is not backward compatible across major version, so a library compiled for scala 2.12.x cannot be used by a project written in scala 2.13.x.
So when writing a scala library, you will need to compile and publish it one time per scala major version you would like to support. When using a library in a project, you would then have to pick the version compiled for the same Scala major version as your are using. Doing this manually would be cumbersome, so SBT has built in support for it.
When publishing a library, you can add the crossScalaVersions key to SBT like
crossScalaVersions := Seq( "2.10.6", "2.11.11", "2.12.3" )
And then publish with sbt +publish. This will make SBT build and publish a version of the library for both scala 2.10.6, 2.11.11 and 2.12.3. Note that the minor number is in-relevant, when it comes to compatibility for libraries. The published libraries, will have the name suffixed with _2.10, _2.11 and _2.12 to show what scala version it is for. An alternative to using the SBT build in support for this, is to use the experimental plugin sbt-projectmatrix as this gives a lot more options, and often faster builds.
When using a library sbt can also help your use the one compiled for the correct scala version, and thats where %% comes into play. When specifying a library without the _ suffix in the name, but instead use %%, then sbt will fill in suffix matching the Scala major version your use, and thereby fetch the correct version of the library.
I'm developing a simple SBT project that includes InputTasks for benchmarking Scala Parallel collections.
I have defined the InputKeys and started writing the tasks when I encountered a problem.
Since my benchmarks require Scala 2.10.0-M5, I tried doing this in my build.sbt:
name := "scala-parallel-collection-benchmark"
version := "1.0.0"
organization := "com.google.summer"
scalaVersion := "2.10.0-M5"
However, at compilation I get the following error:
[info] Loading project definition from C:\Users\Administrator\scala-parallel-collection-benchmark\project
[info] Compiling 1 Scala source to C:\Users\Administrator\scala-parallel-collection-benchmark\project\target\scala-2.9.1\sbt-0.11.3\classes...
[error] C:\Users\Administrator\scala-parallel-collection-benchmark\project\Build.scala:47: value tasksupport is not a member of scala.collection.parallel.mutable.ParArray[Int]
[error] collection.tasksupport = new ForkJoinTaskSupport(new ForkJoinPool(par))
[error] ^
[error] one error found
[error] {file:/C:/Users/Administrator/scala-parallel-collection-benchmark/project/}default-e0b2a2/compile:compile: Compilation failed
It appears that it still uses Scala 2.9.1 to compile it.
How can I set up SBT so it compiles my code using Scala 2.10.0-M5?
scalaVersion only impacts the version of Scala used to compile the "actual" source code (usually located in src/...). Your error comes from a part of the build definition (under project/), which is always compiled with the Scala version that sbt was built with.
You can't modify the version of Scala that is used to to compile the project definition, because it must be a version binary compatible with the version used to compile SBT itself. There's some flexibility being studied in this regard, but, right now, it's fixed.
The setting scalaVersion will change the version of Scala used to compile the project itself. The project can be compiled with completely different versions and, in fact, you can even have SBT compile your project with multiple Scala versions.
you can change the scala version in file "project/build.properties"
e.g. sbt.version=0.11.2
Now I somehow messed up my global sbt plugins (~/.sbt/plugins/build.sbt). They were always fine retrieved against Scala 2.9.1 which seems to be the version that sbt 0.11.3 wants, and all the plugins (sbt-gpg-plugin, sbt-idea-plugin) are published against 2.9.1.
Now whatever I do, it persistently tries to find them built against 2.9.2:
[warn] Note: Some unresolved dependencies have extra attributes. Check that these dependencies exist with the requested attributes.
[warn] com.github.mpeltonen:sbt-idea:1.0.0 (sbtVersion=0.11.3, scalaVersion=2.9.2)
[warn] com.jsuereth:xsbt-gpg-plugin:0.6 (sbtVersion=0.11.3, scalaVersion=2.9.2)
...
[error] {file:...}default-50be6e/*:update: sbt.ResolveException: unresolved dependency: com.github.mpeltonen#sbt-idea;1.0.0: not found
How can I fix this, so sbt retrieves the plugins for Scala 2.9.1 as before?
For the sake of completeness, this is how my files look after the suggestions:
// project-home/build.sbt
scalaVersion := "2.9.2"
...
// project-home/project/plugins.sbt
resolvers += "less is" at "http://repo.lessis.me"
addSbtPlugin( "me.lessis" % "ls-sbt" % "0.1.1" )
scalaVersion := "2.9.1" // "just in case it helps"
// ~/.sbt/plugins/build.sbt
scalaVersion := "2.9.1" // "just in case it helps"
resolvers += "sbt-idea-repo" at "http://mpeltonen.github.com/maven/"
resolvers += Resolver.url( "sbt-plugin-releases", url( "http://scalasbt.artifactoryonline.com/scalasbt/sbt-plugin-releases" ))( Resolver.ivyStylePatterns )
addSbtPlugin("com.github.mpeltonen" % "sbt-idea" % "1.0.0")
addSbtPlugin( "com.jsuereth" % "xsbt-gpg-plugin" % "0.6" )
What is even worse, the problem persists, even after I removed ~/.sbt/plugins/build.sbt. So there are no more references (at least visible to me) to either sbt-idea or xsbt-gpg-plugin. Still I cannot compile any project any more, because sbt still tries to find those two plugins. Epic fail.
You could provide the Scala version of plugin. I didn't use ~/.sbt/, but I think it will works too.
The following is my project configuration using Scala 2.9.2 as my project compiler, and using some pluign that are compiled from Scala 2.9.1. Since Scala 2.9.1 and Scala 2.9.2 is binary compatible, I don't encounter any problem yet.
// MyProject/build.sbt
name := "MyProject"
version := "0.1"
scalaVersion := "2.9.2"
The following is plugin configuration:
// File: MyProject/project/plugins.sbt
import sbt._
import Defaults._
resolvers += Resolver.url("sbt-plugin-releases",
new URL("http://scalasbt.artifactoryonline.com/scalasbt/sbt-plugin-releases/"))(
Resolver.ivyStylePatterns)
// Resolved to:
//
// http://..../com.untyped/sbt-less/scala_2.9.1/sbt_0.11.3/0.4/jars/sbt-less.jar
//
libraryDependencies += sbtPluginExtra(
m = "com.untyped" % "sbt-less" % "0.4", // Plugin module name and version
sbtV = "0.11.3", // SBT version
scalaV = "2.9.1" // Scala version compiled the plugin
)
Some references:
SBT plugins are versioned to the scala version they were built with.
You're not the only one... Again, no answers.
And another case study, this may have answers.
A possibly relevant quote? " Remember to also remove the project/plugins -directory, because if the directory exists, project/plugins.sbt is ignored."
You can also specify sbtVersion and scalaVersion. There is an overloaded addSbtPlugin -
addSbtPlugin(dependency : sbt.ModuleID, sbtVersion : scala.Predef.String, scalaVersion : scala.Predef.String)
Ok, I went back to all the events that could have led to this. And because I found that other projects were still building, I started to understand that the problem with this particular project B was that it appeared that the two plugins were regular dependencies of project A which it depended on.
When sbt refused to acknowledge the presence of the GPG plugin which I uncommented in ~/.sbt/plugins/build.sbt, I renamed that file to ~/.sbt/plugins.sbt, and back again. That intermediate position somehow meant that the plugins were not any more plugins (despite being added as addSbtPlugin), but regular dependencies for the project A when I publish that.
I tried to find that messed up A's ivy.xml across all known Ivy2 cache directories. It was not possible to find the one that sbt was obviously seeing.
Long story, short answer: I had to bump the version of A artificially to get rid of the wrong ivy.xml cached somewhere in a hidden place. That forced sbt to re-find A with the correct ivy.xml (not depending any more on the plugins).
Now I'm just worried what happens if I put my global plugin settings into place :-#
Future advise: Never ever ever put anything into ~/.sbt/plugins.sbt. If you need sbt to understand that you changed ~/.sbt/plugins/build.sbt: Reboot your computer. Don't touch any file.