As described in #2336, I noticed that when using 0.13 nightly from
Bintray, sbt was unable to locate the compiler source.
Since `updateSbtClassifiers` is already set up to download sbt's own
sources, the `ivyConfiguration` should be reused. However, `compilers`
is a derived task, which is unable to depend on a scoped key.
To workaround this I had to create a new key called
`bootIvyConfiguration`. This should now use the metabuild's resolvers
to download the compiler bridge source.
Adds a new setting `useJCenter`, which is set to `false` by default.
When set to `true`, JCenter will be placed as the first external
resolver to find library dependencies.
The implementation of `externalResolvers` is changed to incorporate the
setting by calling `Resolver.reorganizeAppResolvers`. These changes
were required because `externalResolvers` uses whatever that's in the
launchconfig, which the build user may not upgrade.
Even though it's not really used, updateClassifiers constructs
dependency graph based on the result from update.
The direct cause of #2264 came from the fact that the `allModules`
returned from ConfigurationReport did not include dependency
configurations. For example it returned "compile" instead of
"compile->runtime". I've identified that in #2264 and was fixed by
@Duhemm in f49fb33e6d.
Martin identified that the fix still does not address the fact that
updateClassifier hardcodes the classifiers to be tried. This commit
adds the fallback behavior so for Ivy-published modules it will use the
explicit list of artifacts, and for others it will fallback to the
hardcoded list of classifiers.
In order to restore reproducibility of builds, we no longer cascade over
the possibly available versions of the compiler bridge sources (a
specific version of the bridge sources may not be available one day, but
exist on the next day), but rather let the build definition configure
which module to use.
Fixessbt/sbt#2196
This allows for the same functionality that using SettingsDefinition in
Project#settings allows (specifying either bare Setting[_] or a Seq[Setting[_]])
to be available outside of the settings for a project, for instance when
defining a val.
In short, it allows:
val modelSettings = Def.settings(
sharedSettings,
libraryDependencies += foo
)
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.
This provides a convenience function for running an input task from the
extracted state. This is particularly useful for commands, release steps
etc that may want to run input tasks, like scripted.
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. ": _*"
Enumerations always need to start with the same number, otherwise
Scaladoc doesn't recognize them as enumeration (no idea why).
Code blocks need to be surrounded by {{{}}}. The indentation of the
larger code block is still not correctly displayed, but I couldn't find
out why.
A TODO comment is moved out of the Scaladoc comment.
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.
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.
- Fixes cached resolution being too verbose
- Adds new UpdateLogging named "Default"
- When global logLevel or logLevel in update is Debug, Default will
bump up to Full UpdateLogging.
* Force CompileSetup Equiv typeclass to use Equiv relations defined locally.
* Add toString methods on many of the incremental compiler datatypes.
* Remove remaining binary compatibility issues in Defaults.scala.
* Removed as many binary incompatibilities as I could find.
* Deprecating old APIs
* Attempt to construct new nomenclature that fits the design of Incremental API.
* Add as much documentation as I was comfortable writing (from my understanding of things).
This breaks the loading/saving of the incremental compiler analysis out
into separate task, thereby providing the necessary hooks for byte code
enhancement tasks to enhance bytecode and update the analysis before the
analysis gets stored to disk.
Guillaume Martres
Eugene Yokota
Martin Duhem
David Perez
Dale Wijnand
Pierre DAL-PRA
Josh Suereth
Jonas Fonseca
James Roper
Andrew Johnson
Matthew Farwell
Simon Schäfer
Indrajit Raychaudhuri
xuwei-k
andrzej.jozwik@gmail.com
Jean-Rémi Desjardins
j-keck
Tomasz Bartczak