This maintains old, existing ways of configurating project settings,
while adding the possibility to:
* Define add a sequence of settings, between other individual settings
* Pass a Seq[Setting[_]] to Project.settings without having to do
"varargs expansion", ie. ": _*"
Re-fixes cached resolution's internal dependency issue by recursively
calling customResolve instead of including the transitive dependencies
from internal dependencies into your own graph.
Transformation of configuration still happens, but at the level of
resolved graph (UpdateReport), which is much less granular, and
hopefully less error-prone.
- Scala 2.8.x or 2.9.x are no longer used that often.
- Precompiled is a cross build liability as sbt (2.10.4) depends on 2.8.x/2.9.x code.
- Scripted test was modified to check 2.8 and 2.9 compilation
This allows attaching unmanaged sources on `per-ScalaVersion` basis.
Sources from `src/{main,test}/scala-<scalaBinaryVersion>` is collected
in addition to `src/{main,test}/scala` by default.
Note that the treatment of `scalaBinaryVersion` would vary depending on
`scalaVersion` pre-2.10 and 2.10 onwards.
For example:
- with `scalaVersion` `2.9.3`, the `scalaBinaryVersion` is set to `2.9.3`
thus the files in `src/{main,test}/scala-2.9.3` as well
`src/{main,test}/scala` would be available in the `sources` list.
- with `scalaVersion` `2.10.1`, the `scalaBinaryVersion` is set to `2.10`
thus the files in `src/{main,test}/scala-2.10` as well
`src/{main,test}/scala` would be available in the `sources` list.
* 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
The basic mechanism is the same as #1514, which is short circuiting
issue.
For maven there’s the second problem of the availability of the
publication date.
Adds project-level dependency exclusions:
excludeDependencies += "org.apache.logging.log4j"
excludeDependencies += "com.example" %% "foo"
In the first example, all artifacts from the organization
`"org.apache.logging.log4j"` are excluded from the managed dependency.
In the second example, artifacts with the organization `"com.example"`
and the name `"foo"` cross versioned to the current `scalaVersion` are
excluded.
- minigraph sha now contains extra attributes from artifacts
- artifacts are merged from different mini graphs (in some cases, this
should result to better resolution than stock ivy)
When stitching the minigraphs together only exclude the artifacts that
were evicted in *all* graphs, instead of some graphs.
Consider the following scenario:
- Y1 evicts slf4j-api 1.6.6 and picks 1.7.5
- Y2 evicts slf4j-api 1.7.5 and picks 1.6.6
At the root level, we need to use our own judgement and pick 1.7.5.
* Create a new sbt.compiler.javac package
* Create new interfaces to control running `javac` and `javadoc` whether forked or local.
* Ensure new interfaces make use of `xsbti.Reporter`.
* Create new method on `xsbti.compiler.JavaCompiler` which takes a `xsbti.Reporter`
* Create a new mechanism to parse (more accurately) Warnings + Errors, to distinguish the two.
* Ensure older xsbti.Compiler implementations still succeed via catcing NoSuchMethodError.
* Feed new toolchain through sbt.actions.Compiler API via dirty hackery until we can break things in sbt 1.0
* Added a set of unit tests for parsing errors from Javac/Javadoc
* Added a new integration test for hidden compilerReporter key, including testing threading of javac reports.
Fixes#875, Fixes#1542, Related #1178 could be looked into/cleaned up.
When Ivy translates pom to ivy.xml, it adds force=“true”.
So when both non-Maven dependencies and Maven dependencies are mixed, Maven dependencies always wins, which is the case for scala-library dependency added by the user.
Dale Wijnand
Eugene Yokota
Josh Suereth
Indrajit Raychaudhuri
Jean-Rémi Desjardins
Martin Duhem
j-keck