Mention that private members are being extracted and included in the api
structures but ignored in many other parts of incremental compiler. I've
made a mistake of assuming that private members are ignored at api
extraction time. This manifested itself as bug #2324.
Add a pending test that shows a bug in calculation of name hashes.
By design, only non-private members should contribute to name hashes. The
test shows that name hashes are calcuclated for strictly private members
too.
#1520 originally fixed#1514 by reimplementing part of chain resolver
to check all resolvers to find the latest snapshot artifacts.
This behavior did not work well with Maven repositories where sbt was
failing to calculate the correct publication dates.
Now that #2075 fixes the Maven integration issue we should enable this
flag back again.
The build user can opt out by:
updateOptions := updateOptions.value.withLatestSnapshots(false)
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
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
Grzegorz Kossakowski
Dale Wijnand
eugene yokota
Johannes Rudolph
Martin Duhem
Huw Giddens
Stu Hood