It occurs in the midst of the addition of the higher level API for coursier, that should be discussed in a later release. This higher level API aims at being as simple to use as the CLI of coursier.
launchcommands were heavily refactored, to extract bits of the high level API from them. Although best efforts were made to prevent them, these refactoring may come with some regressions. Don't hesitate to report any if ever you run into one.
Tweaking / enhancements
Regular expressions were used during resolution to process Maven properties. Some handcrafted code now handles those, which provides nice performance gains.
Maven POM parsing used to be handled by parsing the POM file itself, then processing the resulting XML AST. It's now handled by a SAX parser, which brought some performance gains too.
In the CLI, and in the upcoming high level API, the default repositories are
- the local Ivy2 repository (
- Maven Central.
These can now be tweaked via the environment, via
COURSIER_REPOSITORIESin the environment,
This environment variable or Java property are expected to contain a list of repositories, separated by
central|sonatype:releases. The repositories themselves are parsed the same way as those passed via the
--repository options of the CLI.
Note that this does not affect the sbt plugin.
Download initial JAR from Central rather than Sonatype releases
The coursier launcher downloads a proguarded version of the CLI of coursier upon first launch. It is now ensured this proguarded JAR is downloaded from Maven Central, rather than Sonatype releases, the former being usually faster than the latter.
Ship completions with launcher
The completions of coursier now ship with the launcher itself. Run
$ coursier --completions zsh
to print the Zsh ones. (Zsh is the only supported shell for now.)
fetch commands now accept a
--sbt-plugin option to accept sbt plugin dependencies. Use like
$ coursier resolve --sbt-plugin com.typesafe.sbt:sbt-native-packager:1.3.3
Adjust the scala and sbt versions with the
sbt-version options, like
$ coursier resolve \ --sbt-plugin com.typesafe.sbt:sbt-native-packager:1.3.3 \ --scala-version 2.10.7 \ --sbt-version 0.13.8
Don't automatically resolve unrecognized dependencies against Scaladex
Formerly, things passed to the CLI not recognized as dependencies were assumed to be Scaladex queries, like
$ coursier launch ammonite
(Note that the Scaladex resolves this against the wrong module for now.)
Scaladex queries now have to be passed explicitly, like
$ coursier launch --scaladex ammonite
Conflicts handling from CLI (work in progress)
resolve command can now print potential conflicts among dependencies, like
$ coursier resolve io.get-coursier:coursier-cli_2.12:1.1.0-M10 --conflicts org.scala-lang:scala-library:2.12.8 was selected, but com.chuusai:shapeless_2.12:2.3.3 wanted version 2.12.4 com.github.alexarchambault:argonaut-shapeless_6.2_2.12:1.2.0-M8 wanted version 2.12.4 com.github.alexarchambault:case-app-annotations_2.12:2.0.0-M5 wanted version 2.12.7 com.github.alexarchambault:case-app-util_2.12:2.0.0-M5 wanted version 2.12.7 com.github.alexarchambault:case-app_2.12:2.0.0-M5 wanted version 2.12.7 org.scala-lang:scala-reflect:2.12.6 wanted version 2.12.6 org.scala-lang.modules:scala-xml_2.12:1.1.1 wanted version 2.12.6 org.typelevel:cats-core_2.12:1.5.0 wanted version 2.12.7 org.typelevel:cats-kernel_2.12:1.5.0 wanted version 2.12.7 org.typelevel:cats-macros_2.12:1.5.0 wanted version 2.12.7 org.typelevel:machinist_2.12:0.6.6 wanted version 2.12.6 org.typelevel:macro-compat_2.12:1.1.1 wanted version 2.12.0 org.scala-lang:scala-reflect:2.12.6 was selected, but io.argonaut:argonaut_2.12:6.2.1 wanted version 2.12.4
--fail-if-conflicts to have a non-zero exit code in case of conflicts.
Beware that these options are a work in progress, more options to filter out conflicts should be added in the future.
Reworked bootstrap launchers
The launchers generated by the
bootstrap command underwent significant changes, most notably the "standalone" launchers.
Standalone launchers contain the JARs they're supposed to launch as resources. Previously, they were setting up a custom
java.net.URLStreamHandlerFactory, to handle custom URL protocols for these JARs. This is no longer the case. Thanks to bits of code imported from the Spring boot loader, these JARs are handled via the
jar protocol, resulting in URLs like
jar:file:…!/. The logic imported from Spring also has the advantage of exposing those JARs to
java.net.URLClassLoader in a way allowing for a performance on par with standard files.
Fix stack overflow when printing trees with cyclic dependencies
1.1.0-M2. For example, the following command works again
$ coursier resolve -t \ -r http://cogcomp.cs.illinois.edu/m2repo \ edu.illinois.cs.cogcomp:illinois-nlp-pipeline:0.1.21
Fail loudly on interrupted downloads from the launcher
The coursier launcher, and the bootstraps it generates, can download some JARs upon first launch. These downloads rely on
java.net.HttpURLConnection for http and https, which sometimes succeeds even if the connection is abruptly interrupted, resulting in invalid JARs. These are now detected in the launcher, which then requests users to try running the launcher again.