sbt was reporting warning abouts inconsistent versions of dependencies
even if these dependencies didn't have the same configuration (as in
`provided` vs `compile`).
This commit fixes this problem by comparing the dependencies by
organization, artifact name and configuration.
Fixessbt/sbt#1933
* origin/0.13.9:
Notes
0.13.9
cached resolution: use mutable map to speed up breakLoops
cached resolution: don't include callers from evicted modules
Add debug logs
Fixes#2129. break up circular dependency loops in cached resolution
try breaking circular dependency and continue sorting
refactored to use less stack space
make sortModules tailrec
Reproduce stack overflow using cached resolution with circular dependency
This commit introduces a mechanism that allows sbt to find the most
specific version of the compiler interface sources that exists using
Ivy.
For instance, when asked for a compiler interface for Scala 2.11.8-M2,
sbt will look for sources for:
- 2.11.8-M2 ;
- 2.11.8 ;
- 2.11 ;
- the default sources.
This commit also modifies the build definition by removing the
precompiled projects and configuring the compiler-interface project so
that it publishes its source artifacts in a Maven-friendly format.
* Remove launch/* code/tests, as these are in the sbt/launcher project.
* Create a new project which will resolve launcher module from sonatype-snapshots,
and repackage it for the currently building version of sbt.
* Remove ComponentManagerTest which was relying DIRECTLY on launcher classes.
We'll need to reconfigure this shortly to enable the tests again.
Remaining TODOs -
* Update resolvers so people can find the launcher.
* Add ComponentManagerTest back.
* Re-publish the sbt-launch.jar in the location it used to be published.
* Here we wire Aether into the Ivy dependency chain
* Add hooks into Aether to use Ivy's http library (so credentials are configured the same)
* Create the actual Resolver which extracts metadata information from Aether
* Deprecate old Ivy-Maven integrations
* Create hooks in existing Resolver facilities to expose a flag to enable the new behavior.
* Create notes documenting the feature.
* Create a new resolver type `MavenCache` which denotes how to read/write local maven cache metadata
correctly. We use this type for publishM2 and mavenLocal.
* Update failing -SNAPSHOT related tests to use new Aether resolver
* Create specification for expected behavior from the new resolvers.
Known to fix#1322, #321, #647, #1616
#1634 is about a library getting wiped out of deps graph when it’s
included twice in ascending order of version.
I’d say that’s a logically inconsistent state, and we should just issue
warning instead of trying to fix it.
I assumed 1.1+ should be treated as 1.+, but it seems like Ivy treats
it more as “any version that starts with 1.1” including 1.10.
Josh’s original implementation approximates this by making ranges for
multiple digits, 1.1~1.2, 1.10~1.20, etc.
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.
Ivy and pom uses slightly different notation for version range and
dynamic revision.
This change fixes the dynamic revisions involving “+”.
First, when a revision like “1.1+” is found, it will now be treated as
“1.+”.
Next, when it finds a revision like “1+” is found, it will be treated
as “+”.
The conversion of “+” is hardcoded to be “[0,)”.
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.
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.
We attempt to convert these constructs to maven:
* 1.+
* ]1,2]
* [2,3[
* 1+ - Albeit this one is a heuristic for accuracy.
This should help ivy users which prefer the nicer 1.2.+ syntax.
Also adds tests/improves exisitng tests.
updated compile tests for new minimal AnalysisCallback
moved discovery to discovery/ subproject and updated for new approach
fixed discovery to only find public methods when searching for annotated definitions
extracting inherited definitions unimplemented in api/, so some discovery tests fail
moved discovery classes from sbt.inc package to sbt.compile
Martin Duhem
eugene yokota
Dale Wijnand
Pierre DAL-PRA
Andrew Johnson
Josh Suereth
Tejas Mandke
David Pratt
Mark Harrah