I just successfully released my first Scala & Scala.js cross-building library to Sonatype and can now use the following two artifacts in my applicatons:
https://search.maven.org/artifact/com.github.fbaierl/scala-tarjan_2.12/0.1.1/jar
https://search.maven.org/artifact/com.github.fbaierl/scala-tarjan_sjs0.6_2.12/0.1.1/jar
My question now is: Why is the Scala and Scala.js version included in the artifact id? I don't think I have seen such a thing before so I was wondering if I did something wrong. Here is my build.sbt: https://github.com/fbaierl/scalajs-cross-compile-tarjan/blob/03954a3e2d1442ad339298a986209c1403c9692e/build.sbt
That's the way that Scala artifacts work. Pretty much all artifacts look like this -- it just isn't obvious when you use those artifacts in sbt, because (IIRC) the _2.12 is implied by the %% operator in sbt. (And the _sjs0.6 is implied by the %%% operator.)
The underlying reason for it is that artifacts compiled by different major versions of the Scala compiler (Scala versions are epoch.major.minor) aren't binary compatible (because otherwise the language and standard library couldn't evolve). You can't mix e.g. _2.12 and _2.11 artifacts on the classpath, so the “same” version of the same library must be published separately for both Scala versions, so the suffix is needed to distinguish them.
Related
I would like to cross-build some of my Bazel targets to Scala 2.12 and 2.13. As a further point of complexity, I need to be able to express cross-target dependencies (eg. some 2.13 target may have a Bazel dependency on a 2.12 target).
Note: this isn't a regular library dependency (eg. with the dependency 2.12-built JAR showing up on the class path when compiling the 2.13 JAR), as that would almost surely result in issues due to having two incompatible versions of the Scala standard library on the class path. Rather, this is just a case where I need the dependency JAR built so I can use it in some integration tests in the 2.13 target.
What I've found online so far...
This issue from rules_scala seems it doesn't support baking the Scala version into the target and instead you have to pick the Scala version globally.
This Databricks post has a cross-building section that is exactly what I think I would like (eg. one target generated per library per supported Scala version), but the snippets in that post don't seem to be backed by any runnable Bazel code.
This later post by Databricks also hints at a cross_scala_lib rule, but also doesn't have any accompanying code.
I modified the source code of scala compiler and built it. Now I want to test this compiler. However, many existing scala projects use sbt as build tool. So I wonder if it is possible to replace the official scala compiler used by sbt with the scala compiler built by myself.
See http://www.scala-sbt.org/1.0/docs/Configuring-Scala.html#Using+Scala+from+a+local+directory:
The result of building Scala from source is a Scala home directory <base>/build/pack/ that contains a subdirectory lib/ containing the Scala library, compiler, and other jars. The same directory layout is obtained by downloading and extracting a Scala distribution. Such a Scala home directory may be used as the source for jars by setting scalaHome. For example,
scalaHome := Some(file("/home/user/scala-2.10/"))
If you want to publish the compiler, use #ipoteka's answer.
According to docs it's straightforward:
managedScalaInstance := false
libraryDependencies += "yourPackage" % "yourScalaCompiler" % version
Don't forget to publish-local you compiler first.
I had been using Scalariform in a project I upgraded to Scala 2.11. In doing so, I discovered that Scalariform does not appear to have an artifact published for 2.11 in any of the usual places. This makes the usual sbt cross-version dependency unhappy.
As 2.11 has been out for a while already, this has me questioning if the usage of Scalariform as an embedded library should be considered abandoned? Has the community moved on to an alternative I just don't know about?
Scalafmt is an alternative code formatter that does compile to 2.11 and can be used as an embedded library. An up-to-date usage example is here https://olafurpg.github.io/scalafmt/#Standalonelibrary
I just updated a project which was using macro-paradise 2.0 snapshot under 2.10; with the final version of macro-paradise 2.0 it tells me the following when I compile under 2.10 (not 2.11):
Quasiquotes in macro paradise for Scala 2.10 require a dependency on a supporting library. Add the following line to your SBT build: libraryDependencies += "org.scalamacros" %% "quasiquotes" % "2.0.0"
Now I'm worried because that dependency turns up as a regular dependency of my published Maven artifact. Is this really so? Or isn't Quasiquotes perhaps just a compile-time dependency that should not be needed for the published artifact?
If so, should I go through these hoops to get rid of the artifact, i.e. % "compileonly"?
Macros that use quasiquotes provided by recent versions of paradise for Scala 2.10, i.e. 2.0.0-M4+, including 2.0.0 and later ones, will almost always require the supporting library to be on classpath when expanding (very simple quasiquotes don't require the library, but that's quite rare).
Therefore if you want users of your library to also use macros that you've written with quasiquotes, you'll need to export "org.scalamacros" %% "quasiquotes" % "2.x.y" in your pom file or rely on someone else to provide this dependency for your users.
Well, I just tried the approach in the linked question to create a special "compileonly" configuration and thus remove it from the exported POM. It was possible to use the library in Scala 2.10 even with Quasiquotes absent.
I've just downloaded Play Framework 2.1-RC1.
Within folders, I noticed that SBT folder includes itself Scala's compiler/library whose version is:
scala.2.10.0-RC1.
Previously, I used to compile some Scala programs with the more recent version:
scala.2.10.0-RC2
Should I stay with scala.2.10.0-RC1 provided by Play (in order to avoid potential incompatibility with Play)?
Further, is there a way (a specific Play's command-line?) to add automatically src-jars for Scala into Play's SBT folder (scala-library-src.jar etc...)? Indeed the folder structure contains currently only jars files:
jansi.jar
jline.jar
scala-compiler.jar
scala-library.jar
scala-reflect.jar
Scala 2.10.0 final has been out for about a week, now. I'd expect that the Play artifacts are available for it by now and if they're not they surely will be soon.