Ref https://github.com/sbt/sbt/issues/6912
Problem
-------
There's apparently a security issue with OkHttp 3.x,
which I am not really sure how applicable it is to our usage
of OkHttp but it is there.
Solution
--------
Since most of OkHttp-specic usage within LM is for Apache Ivy
downloading, I am going to drop this.
Since `sbt.librarymanagement.Http.http` is a public API,
I am substituting this with Apache HTTP backed implementation.
Rather than seeing an error like this, with the evicted version numbers
being repeated many times:
```
[error] * org.scala-lang.modules:scala-java8-compat_2.13:1.0.0 (early-semver) is selected over {0.9.0, 0.9.0, 0.9.0, 0.9.0, 0.9.1, 0.9.1, 0.9.1}
```
...I'd much rather see an error like this:
```
[error] * org.scala-lang.modules:scala-java8-compat_2.13:1.0.0 (early-semver) is selected over {0.9.0, 0.9.1}
```
Fixes https://github.com/sbt/sbt/issues/6578
Problem
-------
The regex currently expects two segments like2.x or 3.x,
but Scala 3 uses _3 as the cross suffix, and it's not caught.
Solution
--------
Change the regex.
Ref #377
Apply the dotted-prerelease tag to SemComparator
"A pre-release version MAY be denoted by appending a hyphen and a series of dot separated identifiers immediately following the patch version."
What is the problem?
sbt/sbt#6496 identifies a bug in the logic which assesses whether
different versions of the same transitive dependency are binary
compatible. If one of the transitive dependencies included a version
with a full-stop literal, it would be parsed incorrectly and an error
would be thrown to the user falsely saying that the dependencies are
binary incompatible.
What is the solution?
This PR fixes the regex used by the parser to include full-stop literals.
Is there anything else to be done?
It is worth us checking the rest of the codebase in case this bug might
exist in other parsers. The tests are super helpful for figuring out
which strings might break the current logic.
Ref https://eed3si9n.com/enforcing-semver-with-sbt-strict-update
This adds EvictionError, a replacement for EvictionWarning.
The problem with the current eviction warning is that it has too many
false positives. Using the versionScheme information that could be
supplied by the library authors and/or the build users, this eliminates
the guessing work. At which point, we can fail the resolution.
Fixes https://github.com/sbt/sbt/issues/6210
scodec-bits is published with pvp versionScheme (nice), this means that
we should just evaluate the version portion for pvp-ness, but I was
using `guessSecondSegment` that checks for Scala suffix. That's mistake
1.
`guessSecondSegment` assumes that the Scala suffix uses the given
ScalaModuleInfo, but with 2.13-3 sandwich we can't assume this.
In the reported case, Scala module is 3.0.0-M3 but scodec-bits uses
2.13. So that's mistake 2.
This attempts to correct both the mistakes.
1. Instead of `guessSecondSegment`, this adds a simpler `evalPvp`
function.
2. `guessSecondSegment` just looks for `_2.` or `_3` and ignores the
Scala module.
This extracts info.versionScheme from POM and uses that to guide the
eviction report instead of taking a stab in the dark that all Scala
libraries are using pvp.
Fixes https://github.com/sbt/sbt/issues/3570
The primary motivation for bringing in Gigahorse was to speed up the dependency resolution, especially in a high-latency environment like Australia, by enabling keep-alive. One of unintended consequences was that it ended up exposing either a bug in okhttp or Nexus / Artifactory's handling of keep-alive, since corporate users behind these proxy repositories started to experience problem publishing. Multiple people have also reported that putting network proxies like HAProxy works around this issue, which seems consistent with the theory.
Now that dependency resolution has switched to using Coursier by default, I am just going to flip the default here so publishing would use Ivy's default URL handler based on `java.net.HttpURLConnection` - 5681e1a77a/src/java/org/apache/ivy/util/url/BasicURLHandler.java