Problem
In sbt 1, platform cross building is implemented using in the user-land
using `%%%` operator, which clevery handles both Scala cross building
and appending platform suffix like sjs1.
However, in general symbolic `%%%` is confusing, and hard to explain.
Solution
In sbt 2, we should subsume the idea of platform cross building,
so `%%` can act as the current `%%%` operator.
This adds a new field called `platformOpt` to `ModuleID`, which
by default will be set to `None`.
`ScalaModuleInfo` will also add a new field called `platform`,
which can be set to `None`, `Some(sjs1)` etc.
As part of module transformation (like adding `_2.13`), the library
management engine can transform `ModuleID` to `sjs1` etc.
`("com.github.scopt" %% "scopt" % "4.1.0").platform(jvm)` will
explicitly use the JVM version of dependency (equivalent to today's `%%`).
sbt plugins were published to an invalid path with regard to Maven's
specifictation.
As of sbt 1.9 we produce two POMs, a deprecated one and a new one,
that is valid with regard to Maven resolution. When resolving,
we first try to resolve the new valid POM and we fallback to
the invalid one if needed.
In the new POM format, we append the sbt cross-version to all
artifactIds of sbt plugins. This is because we want Maven to be
able to resolve the plugin and all its dependencies.
When parsing it, we remove the cross-version suffix so that
the result of parsing the valid POM format is exactly the same
as parsing the deprecated POM format. Hence conflict resolution
happens as intended.
More details can be found at https://github.com/sbt/sbt/pull/7096
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.
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 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.