This code originates from a PR against sbt 0.13:
https://github.com/sbt/sbt/pull/2576
The sbt/librarymanagement part was forward-ported to
sbt/librarymanagement and merged, while the sbt/sbt part wasn't.
So let's get rid of this so we can drop the dependency on
util-completion.
To ease migrating code from sbt 0.13 to sbt 1 this introduces val and
type aliases to CrossVersion's companion object (via
CrossVersionFunctions).
In addition, for consistency, it introduces CrossVersion.disabled.
sbt 1 removes CrossVersion.binaryMapped which was used in the sbt-dotty
plugin to provide a way to depend on Scala 2.x artifacts in a project
that cross-compiles between Scala 2.x and Dotty (see `withDottyCompat()` in
https://github.com/lampepfl/dotty/blob/master/sbt-dotty/src/dotty/tools/sbtplugin/DottyPlugin.scala).
Using `binaryWith` is not enough because it only allows the user to
specify a prefix and a suffix for the binary version which will always
be set to `scalaBinaryVersion`. This commit introduces a new `Constant`
kind of CrossVersion which allows the user to specify any string he
wants as a cross-version, thus making it possible to port
`withDottyCompat()` to sbt 1.
Fixessbt/sbt#2699
Before:
[warn] There may be incompatibilities among your library dependencies.
[warn] Here are some of the libraries that were evicted:
[warn] * com.google.code.findbugs:jsr305:2.0.1 -> 3.0.0
[warn] Run 'evicted' to see detailed eviction warnings
After:
[warn] Found version conflict(s) in library dependencies; some are suspected to be binary incompatible:
[warn]
[warn] * com.typesafe.akka:akka-actor_2.12:2.5.0 is selected over 2.4.17
[warn] +- de.heikoseeberger:akka-log4j_2.12:1.4.0 (depends on 2.5.0)
[warn] +- com.typesafe.akka:akka-parsing_2.12:10.0.6 (depends on 2.4.17)
[warn] +- com.typesafe.akka:akka-stream_2.12:2.4.17 () (depends on 2.4.17)
[warn]
[warn] Run 'evicted' to see detailed eviction warnings
Dotty is versioned as 0.*, but `CrossVersionUtil#binaryScalaVersion`
will return the full version instead of just `major.minor` for all
compiler versions < 2.10, add a special case for Dotty to avoid this.
`UpdateOptions` is only meant for user-provided options. Since this
option should not be exposed to users, it's moved to inline ivy
configuration, whose parameters require information about the build and
is usually defined project-wide instead of `Global`-wide.
Managed checksums tells ivy to forget about checking checksums for jar
files and just persist them in the cache.
The user that enables that option will take care of verifying they are
correct.
This is a big deal because:
1. Ivy takes *a lot of time* checking timestamps for big jars, and does
it sequentially. The user (sbt) can do better by running these checks
in parallel, speeding up the whole resolution process!
2. The fact that the sha files are not present in the cache means that
build tools cannot check if a checksum is correct without preprocessing
the jar.
Note that the user is responsible for keeping the cache consistent. If
the checksum is not correct, the user should report it and overwrite the
checksum file with the valid digest.
Sometimes, for predictability and performance, we may be interested in
specifying the concrete resolver that a `ModuleID` should use.
This patch achieves this by adding a new field to `UpdateOptions` and
then getting this information from the `SbtChainResolver`, that will
select the concrete resolver for a given dependency descriptor.
Why is this useful? Well, two reasons:
* Predictable behaviour. We have the guarantee that an artifact only
comes from a concrete resolver.
* Resolution speedup. Around 1/3 or 1/2 times faster than normal
resolution in a moderate test case scenario. If there is a lot of
latency or network connection is poor, speedups will be higher.
LOGS:
```
NORMAL RESOLUTION TIME 1790
FASTER RESOLUTION TIME 1054
```
```
NORMAL RESOLUTION TIME 2078
FASTER RESOLUTION TIME 1055
```
Lots of projects can benefit from this option, as well as organizations
and companies. This will eventually integrate with the dependency lock
file, but can be used independently of it.
To ensure that SNAPSHOTs are always the latest, we go through all the
resolved modules and check their timestamps. Good.
However, if in the process of reparsing/redownloading the module
descriptor we fail (or it's not found in that resolver at all), then we
cannot refresh the resolved module that could have been internalized or
heavily cached in memory by ivy. We do this for correctness.
This patch does two things:
1. Adds more comments.
2. Warns only when there are parsing errors in ivy files.
3. Adds debug info in the rest of the cases.
This removes the pain of seeing `Unable to parse` that could be caused by
other reasons that are not related to parsing at all and which would not
affect the algorithm at hand. For instance, if we get a URLResource,
that's totally fine -- there is no way we could parse the ivy file. Ivy
uses URLResources in several cases where the artifact origin URL is
specified.
Dale Wijnand
eugene yokota
Guillaume Martres
jvican