It turns out there was a very subtle, and evil, issue sitting the Ivy/maven configuration, and it
related to dependency mapping. A mapping of `foo->bar(*)` means that the local configuration
`foo` depends on the remote configuration `bar`, if it exists, or *ALL CONFIGURATIONS* if `bar`
does not exist. Since the default Ivy configuration mapping was using the random `master`
configuration, which AFAICT is NEVER specified, just an assumed default, this would cause leaks
between maven + ivy projects.
i.e. if a maven POM depends on a module denoted by an ivy.xml file, then you'd wind up accidentally
bleeding ALL the ivy module's configurations into the maven module's configurations.
This fix works around the issue, by assuming that if there is no `master` configuration, than the
maven default of `compile` is intended. As sbt forces generated `ivy.xml` files to abide by
maven conventions, this works in all of our test cases. The only scenario where it wouldn't work
is those who have custom ivy.xml files *and* have pom.xml files which rely on those custom ivy.xml files,
a very unlikely situation where the workaround is: "define a master configuration".
Includes a test demonstrating the issue.
Fixes#1565
* Create two chains if we have inter-project resolver
- One which ensures inter-project deps are always taken
- One which will look in all "other" repositories for
dependencies and will use the "most up-to-date" -SNAPSHOT
strategy.
* No additional tests, as this would simple break every
multi-project test if it were wrong.
There is sometimes the need to use a test version of Scala that is
intended to be binary compatible with a standard release version.
At this time, due to the particular logic implemented within sbt,
a non-numeric suffix will never have the same binaryScalaVersion
of a release version ending in ".0", like for instance "2.11.0".
This commit allows developers to use as suffix any string that
begins with "-bin", for instance "2.11.0-bin-compat-test-1".
Such a suffix will have a binaryScalaVersion of "2.11", being
therefore considered binary compatible with release versions.
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.
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 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,)”.
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")
Jean-Rémi Desjardins
Eugene Yokota
Brian Topping
Josh Suereth
Grzegorz Kossakowski
Antonio Cunei
Havoc Pennington