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.
The checking code has bad run time characteristics and would need to be fixed
for large projects with deep task dependency chains.
The code in sbt.Execute has been in production for a long time so it seems safe
enough to drop the extra checks by default. To debug issues, you can set
`-Dsbt.execute.extrachecks=true` to revert to the old behavior.
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.
Upon startup, javac may report errors because (for instance) because it
received incorrect flags. These errors were not correctly parsed by the
JavaErrorParser and were never reported to the user.
This commit fixes this problem by adding a new parsing rule in
JavaErrorParser: errors that start with the prefix "javac:" are now
correctly parsed and reported to the user.
Fixessbt/sbt#2256
These options can only be given to a forked Java compiler. If we run a
local java compiler, we filter these options out and emit a warning.
Fixessbt/sbt#1968
In some cases, the local java compiler may report compilation errors,
but succeed in compiling the source files (for instance, if there are
encoding problems in the source). However, the command line javac will
report a failed compilation on the same input.
To have the local java compiler behave like the forked java compiler, we
now report the compilation as failed if error messages have been
registered during compilation.
Fixessbt/sbt#2228
The signatures of methods that have value classes as arguments or return
type change during the erasure phase. Because we only registered
signatures before the erasure, we missed some API changes when a class
was changed to a value class (or a value class changed to a class).
This commit fixes this problem by recording the signatures of method
before and after erasure.
Fixessbt/sbt#1171
eugene yokota
Johannes Rudolph
Martin Duhem
Dale Wijnand
Huw Giddens
Stu Hood