Fixes sbt/sbt#4595
Ref #290
Ref #280
This is bit of an odd one.
To keep bincompat and also to fix sbt 0.13 compatibility issue we have made `Disabled` companion object extend `Disabled` type.
This actually created a subtle deserialization issue:
```
[error] scala.MatchError: Disabled() (of class sbt.librarymanagement.Disabled$)
[error] at sjsonnew.FlatUnionFormats$$anon$5.write(FlatUnionFormats.scala:220)
[error] at sjsonnew.JsonWriter.addField(JsonFormat.scala:40)
[error] at sjsonnew.JsonWriter.addField$(JsonFormat.scala:37)
[error] at sjsonnew.FlatUnionFormats$$anon$5.addField(FlatUnionFormats.scala:208)
[error] at sjsonnew.Builder.addField(Builder.scala:43)
[error] at sbt.librarymanagement.ModuleIDFormats$$anon$1.write(ModuleIDFormats.scala:46)
```
This is because Contraband generates `flatUnionFormat5[CrossVersion, Disabled, ...]` for all of the subtypes of `CrossVersion`, which uses the runtime type information. Now that `Disabled` object is also in the mix, this created JSON that `CrossVersionFormats` cannot deserialize. This brings the code into src/ so we can write this part manually.
Ref https://github.com/sbt/librarymanagement/pull/280
This is to workaround bincompat error detected by sbt community build.
```
[cats] [error] java.lang.NoSuchMethodError: sbt.librarymanagement.CrossVersion$.Disabled()Lsbt/librarymanagement/Disabled$;
```
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!)
Fix https://github.com/sbt/sbt/issues/3585.
Gigahorse.config tries to load specified config file in sbt's classpath
and of course fail to find the specified config file, and throw
java.io.IOException if we specify config.resource, because
We can avoid trying to load specified config file inside sbt by
avoid using Gigahorse.config that call `ConfigFactory.load()` inside.
This commit fixes librarymanagement not to use Gigahorse.config and make
it use gigahorse.Config() which returns gigahorse's default config
without calling `ConfigFactory.load()` instead.
- When major, minor, and patch are equal, a pre-release version has lower precedence than a normal version. Example: 1.0.0-alpha < 1.0.0.
- Precedence for two pre-release versions with the same major, minor, and patch version MUST be determined by comparing each <del>dot</del> hyphen separated identifier from left to right until a difference is found as follows
- identifiers consisting of only digits are compared numerically and identifiers with letters or hyphens are compared lexically in ASCII sort order.
- Numeric identifiers always have lower precedence than non-numeric identifiers.
- A larger set of pre-release fields has a higher precedence than a smaller set, if all of the preceding identifiers are equal.
- Example: 1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-alpha.beta < 1.0.0-beta < 1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0-rc.1 < 1.0.0.
https://semver.org/#spec-item-11
I noticed this was showing up in profiles when SBT's task engine
was using Keys, etc (that contain Configurations) in HashMap's.
Let's cache it instead. I don't think there is a need to use a lazy
val for this, we can compute it eagerly.
There are just too many instances in which sbt's code relies on
the `lastModified`/`setLastModified` semantics, so instead of moving
to `get`/`setModifiedTime`, we use new IO calls that offer the new
timestamp precision, but retain the old semantics.
Eugene Yokota
bigwheel
Dale Wijnand
tanishiking
Leonard Ehrenfried
xuwei-k
Peter Neyens
Dale Wijnand
Antonio Cunei
Jason Zaugg
exoego
Andreas Jim-Hartmann
Antonio Cunei