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
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.
Rather than
[warn] There may be incompatibilities among your library dependencies.
[warn] Run 'evicted' to see detailed eviction warnings
[info] Done updating.
[warn] There may be incompatibilities among your library dependencies.
[warn] Run 'evicted' to see detailed eviction warnings
[info] Done updating.
[warn] There may be incompatibilities among your library dependencies.
[warn] Run 'evicted' to see detailed eviction warnings
[info] Done updating.
[warn] There may be incompatibilities among your library dependencies.
[warn] Run 'evicted' to see detailed eviction warnings
I would get:
[warn] There may be incompatibilities among your library dependencies; run 'evicted' to see detailed eviction warnings
[info] Done updating.
[warn] There may be incompatibilities among your library dependencies; run 'evicted' to see detailed eviction warnings
[info] Done updating.
[warn] There may be incompatibilities among your library dependencies; run 'evicted' to see detailed eviction warnings
[info] Done updating.
[warn] There may be incompatibilities among your library dependencies; run 'evicted' to see detailed eviction warnings
which is a touch better. (IMO!)
Fixes https://github.com/sbt/librarymanagement/issues/229
OfflineModeSpec is failing often because it asserts that the offline resolution needs to happen within 30% of the original resolution, and I guess it really depends on the weather how much portion of it spends on resolution.
João Ferreira
Eugene Yokota
Adrien Piquerez
Matthew de Detrich
xuwei-k
Peter Janssen
Guillaume Massé
izharahmd
bigwheel
Dale Wijnand
OlegYch
Dennis Hörsch
exoego
Peter Vlugter