would be ok. However, given that the release may contain fixes to scripts and also because your initial resolution would be faster with *.(zip|tgz|msi) that contains all the JAR files, we recommend you use the installer distribution. They will be available from SDKMAN etc.
Notes about Homebrew
Homebrew maintainers have added a dependency to JDK 13 because they want to use more brew dependencies brew#50649. This causes sbt to use JDK 13 even when java available on PATH is JDK 8 or 11.
I’ve just released Zinc 1.4.0-M1. Note this is a beta release and it won’t be compatible with future 1.4.x, but I chose a commit fairly close to 1.3.x so it should be usable.
Replaces ZipUtils usage of deprecated java.util.Date with java.timezinc#714 by @slandelle
Zinc is an incremental compiler for Scala. Though Zinc is capable of compiling Scala 2.10 ~ 2.13 and Dotty, thus far Zinc itself has been implemented using Scala 2.12. This is fine for sbt 1.x, which is also implemented in Scala 2.12, but there’s been requests to cross build Zinc for 2.13.
This is part 3 of the post about sbt-projectmatrix, an experimental plugin that I’ve been working to improve the cross building in sbt. Here’s part 1 and part 2. I’ve just released 0.5.0.
recap: building against multiple Scala versions
After adding sbt-projectmatrix to your build, here’s how you can set up a matrix with two Scala versions.
ThisBuild/ organization :="com.example"ThisBuild/ scalaVersion :="2.12.10"ThisBuild/ version :="0.1.0-SNAPSHOT"lazyval core =(projectMatrix in file("core")).settings( name :="core").jvmPlatform(scalaVersions =Seq("2.12.10","2.11.12"))
This will create subprojects coreJVM2_11 and coreJVM2_12. Unlike ++ style stateful cross building, these will build in parallel. This part has not changed.
I joined Lightbend (then Typesafe) in March, 2014. After six incredible years April 7, 2020 was my last day. I am grateful that I got the opportunity to work with an amazing group of people at Lightbend, partners, customers, and various people I got to meet at conferences. Looking back, before COVID-19 times, it’s almost surreal that I was flying to Europe, Asia, and North America every few months to attend conferences and tech meetings.
Last week I wrote about #8820, my proposal to add user-land compiler warnings in Scala. The example I had was implementing ApiMayChange annotation.
package foo
import scala.annotation.apiStatus, apiStatus._@apiStatus("should DSL is incubating, and future compatibility is not guaranteed", category =Category.ApiMayChange, since ="foo-lib 1.0", defaultAction =Action.Warning,)implicitclassShouldDSL(s:String){def should(o:String):Unit=()}
This was ok as a start, but a bit verbose. If we want some API status to be used frequently, it would be cool if library authors could define their own status annotation. We’re going to look into doing that today.
As a library author, I’ve been wanting to tag methods in Scala that can trigger custom warnings or compiler errors. Why would I want to intentionally cause a compiler error? One potential use case is displaying a migration message for a removed API.
Restligeist macro: n. A macro that fails immediately to display migration message after implementation has been removed from the API.
The relationship given to Int and Long should be exactly the same as the relationship third-party library like Spire can write UInt or Rational with the first-class numeric types.
We should make 1 == 1L an error under strictEquality
We should allow custom types to participate in constant expression conversion using FromDigits
I added a small app called giter8-launcher for Giter8 0.12.0. The purpose of the app is to make the behavior of the Giter8 template more predictable. Today, template authors may create a template for some version of Giter8 X, but the users might use some other version of Giter8 Y that ships with “sbt new.”
One of the neat ideas about sbt is that no matter what version of sbt script users might have it installed, the core sbt version is specified by the build author using project/build.properties file. This significantly reduces the it-only-works-on-my-machine problem. giter8-launcher is analogous to sbt’s sbt-launcher. giter8-launcher clones the template and reads project/build.properties file to determine the Giter8 version to render the template.
Template authors can now specify the Giter8 version in project/build.properties file as:
This is part 2 of the post about sbt-projectmatrix, an experimental plugin that I’ve been working to improve the cross building in sbt. Here’s part 1. I’ve just released 0.4.0.
recap: building against multiple Scala versions
After adding sbt-projectmatrix to your build, here’s how you can set up a matrix with two Scala versions.
ThisBuild/ organization :="com.example"ThisBuild/ scalaVersion :="2.12.10"ThisBuild/ version :="0.1.0-SNAPSHOT"lazyval core =(projectMatrix in file("core")).settings( name :="core").jvmPlatform(scalaVersions =Seq("2.12.10","2.11.12"))
This will create subprojects coreJVM2_11 and coreJVM2_12. Unlike ++ style stateful cross building, these will build in parallel. This part has not changed.
Pamflet is a publishing application for short texts, particularly user documentation of open-source software.
Pamflet 0.8.2 updates its monospace typeface to SFMono, and undoes the incidental pink color that got introduced when I migrated from Blueprint to Bootstrap.
The semantics of a dependency resolver determine the concrete classpath based on the user-specified dependency constraints. Typically the differences in the details manifest as different way the version conflicts are resolved.
Maven uses nearest-wins strategy, which could downgrade transitive dependencies
Ivy uses latest-wins strategy
Coursier generally uses latest-wins strategy, but it’s tries to enforce version range strictly
Ivy’s version range handling goes to the Internet, which makes the build non-repeatable
Coursier orders version string completely differently from Ivy
Last year I wrote an experimental sbt plugin called sbt-projectmatrix to improve the cross building in sbt. I’ve just released 0.2.0.
building against multiple Scala versions
After adding sbt-projectmatrix to your build, here’s how you can set up a matrix with two Scala versions.
ThisBuild/ organization :="com.example"ThisBuild/ scalaVersion :="2.12.8"ThisBuild/ version :="0.1.0-SNAPSHOT"lazyval core =(projectMatrix in file("core")).settings( name :="core").jvmPlatform(scalaVersions =Seq("2.12.8","2.11.12"))
This will create subprojects coreJVM2_11 and coreJVM2_12.
Unlike ++ style stateful cross building, these will build in parallel.
Change originalRepoURL, master, and path/to/keep to appropriate values. Use -- --all to handle all branches.
split a subdirectory into a new repo (complex case)
In case you have multiple paths you want to filter, you need to use --index-filter together with GNU xargs and GNU sed available via brew install gnu-sed findutils.
This is a second post on installing your own JDKs on Travis CI. Previously I’ve written about jabba.
Today, let’s look at SDKMAN!, an environment manager written by Marco Vermeulen (@marc0der) for JDKs and various tools on JVM, including Groovy, Spark, sbt, etc.
AdoptOpenJDK 11 and 8
Update 2020-09-23: Updated the regex of version number.
Update 2019-11-06: Added sdkman_auto_selfupdate to workaround the update prompt blocking the CI. Also it adds || true on the sdk install line.
Update 2019-07-08: Updated the script to detect patch version. See GitHub for the older version.
Here’s how we can use SDKMAN! on Travis CI to cross build using AdoptOpenJDK 11 and 8:
‘Ancillary Justice’ is written in a first-person narrative as the AI of thousands of years old starship Justice of Toren of The Radchaai Empire. Another interesting part is since the Radchaai language is genderless, the narrator constantly describes everyone as “she,” but later you might discover that some character might be he. There are other small details here and there that narrator might say, but you start to question it as the story develops. In other words, Ann Leckie has done a stylish job of show-and-not-tell about the world that she’s built.
As of Scala 2.13.0-M5, it’s planned that scala.Seq will change from scala.collection.Seq to scala.collection.immutable.Seq. Scala 2.13 collections rework explains a bit about why it’s been non-immutable historically. Between the lines, I think it’s saying that we should celebrate that scala.Seq will now be immutable out of the box.
Defaulting to immutable sequence would be good for apps and fresh code. The situation is a bit more complicated for library authors.
If you have a cross-built library, and
if your users are using your library from multiple Scala versions
and your users are using Array(...)
this change to immutable Seq could be a breaking change to your API.
