scala-library is currently treated as just one of the library modules.
This means that it’s at the mercy of eviction if some other library
uses newer version of scala-library.
This commit displays a instruction on how to force scalaVersion if
warnScalaVersionEviction flag is true on EvictionWarningOptions.
Scala instance is added to the Ivy graph via autoLibraryDependency.
For metabuilds, scala-library is scoped under “provided” configuration,
which does not seem to evict modules on “compiled” configuration.
This commit turns overrideScalaVersion flag to true for the metabuilds,
so override rules are added for the following modules:
- scala-library
- scala-compiler
- scala-reflect
Ivy gives an array that contains null for caller configurations.
sbinary barfs when it sees null. Curiously two of the sbt plugins that
hit this bug happens to be from Typesafe:
addSbtPlugin("com.typesafe.play" % "sbt-plugin" % "2.3.2")
addSbtPlugin("com.typesafe.sbt" % "sbt-native-packager" % "0.7.3")
Adds `lastestSnapshots` flag to `updateOptions`, which controls the behavior of the chained resolver. Up until 0.13.6, sbt was picking the first `-SNAPSHOT` revision it found along the chain. When is enabled (default: ), it will look into all resolvers on the chain, and compare them using the publish date.
The tradeoff is probably a longer resolution time if you have many remote repositories on the build or you live away from the severs. So here's how to disable it:
updateOptions := updateOptions.value.withLatestSnapshots(false)
Ivy by default uses latest-revision as the latest strategy. This strategy I don't think takes in account for the possibility that a changing revision may exist in multiple repositories/resolvers with having identical version number like 0.1.0-SNAPSHOT.
The implementation is a bit hacky, but I think it attacks the core of this problem.
Commit a1e26ca6 broke the `make-pom` & `pom-advanced` dependency-management
tests by replacing one reference to `IBiblioResolver.DEFAULT_M2_ROOT` in
`Resolver`, but not the other reference in `MakePom`:
https://travis-ci.org/sbt/sbt/jobs/31939788#L2517-L2519
...the secure url was no longer recognised as the default Maven Repository
root, so was erroneously exported.
UnresolvedWarning is moved back to IvyActions.scala where it belongs.
The mapping between ModuleID and SourcePosition is passed in as UnresolvedWarningConfiguration.
This is calculated once in Defaults using State and is cached to filesystem.
Unresolved dependency warning is moved to UnresolvedDependencyWarning class including
the fail path that was added in #1467.
To display the source position, I need to access the State, so I had to move the
error processing out of IvyActions and add UnresolvedDependencyWarning, which is
aware of State.
This implements all stories from https://github.com/sbt/sbt/wiki/User-Stories%3A-Conflict-Warning.
When scalaVersion is no longer effective an eviction warning will display.
Scala version was updated by one of library dependencies:
* org.scala-lang:scala-library:2.10.2 -> 2.10.3
When there're suspected incompatibility in directly depended Java libraries,
eviction warnings will display.
There may be incompatibilities among your library dependencies.
Here are some of the libraries that were evicted:
* commons-io:commons-io:1.4 -> 2.4
When there's suspected incompatiblity in directly depended Scala libraries,
eviction warnings will display.
There may be incompatibilities among your library dependencies.
Here are some of the libraries that were evicted:
* com.typesafe.akka:akka-actor_2.10:2.1.4 -> 2.3.4
This also adds 'evicted' task, which displays more detailed eviction warnings.
VersionNumber is a pseudo-case class that represents any form of
version number. The unapply extractor can parse String into
three sequences that makes up VersionNumber.
VersionNumberCompatibility trait uses two VersionNumber instances
to evaluate binary compatibility between them.
Two implementations SemVer and SecondSegment are provided.
Currently sbt's update task generates UpdateReport from
Ivy's resolution report.
For each configuration there's ConfigurationReport, which contains
just enough information on the resolved module/revision/artifact.
Speaking of module, in Ivy module means organization and name,
and organization, name, and version is called module revision.
In sbt, module revision is called Module.
This is relevant because to talk about evictions, we need
a terminology for organization and name combo.
In any case ConfigurationReport is expanded to have `details`
field, which contains Seq[ModuleDetailReport], which represents
organization and name combo plus all the modules
just like Ivy's resolution report XML.
Furthermore, ModuleReport is expanded to include licenses,
eviction, callers, etc.
This adds a new setting key called updateOptions, which can enable
consolidated resolution for update task.
The consolidated resolution automatically generates an artificial
module descriptor based on the SHA-1 of all external dependencies.
This consolidates the Ivy resolution of identical Ivy dependency
graph across multiple subprojects.
This is how it's enabled:
updateOptions := updateOptions.value.withConsolidatedResolution(true)
The CustomPomParser has a hard-coded list of 'blessed' Maven POM packaging types
that are actually packaged as jar files, but Ivy incorrectly maps the file extension.
This patch allows artifacts published with the 'scala-jar' packaging to be properly
resolved and used in an SBT project.
Add scala 2.11 test/build verification.
* Add 2.11 build configuratoin to travis ci
* Create command which runs `safe` unit tests
* Create command to test the scala 2.11 build
* Update scalacheck to 1.11.4
* Update specs2 to 2.3.11
* Fix various 2.11/deprecation removals
and other changes.
Fix eval test failure in scala 2.11 with XML not existing.
Ivy transactional publishing will abort if no artifacts
are published, either because the temporary directory is
not being created, or because Ivy will detect an anomalous
condition.
Therefore, skip publishing altogether if there is
nothing to publish to begin with.
* sbt 0.12.3 introduced sbt/sbt@482f99 to fix#637 and #641.
* The underlying issue of #641 was an incorrect classifier, and it was
fixed in sbt/sbt@718fa9 for #683 and shipped as sbt 0.13.0.
* Testing the infrastructure to use our own instance of ivy
* Allow us to push bug-fixes/performance directly into ivy
on our own pace, as we submit patches back to ivy master
Workaround for #1156.
* Creates a new FileRepository that will stil allow local files
to be transfered if overwrite is true (non-snapshot module),
but will issue a warning about deprecated behavior.
* Ensure warning is long enough to annoy people into asking
what it's about.