This is at debug instead of disabled so as to be a minimal change
during a point release. It is dropped to debug because the conflict warnings
don't work correctly, especially for the artifacts they were designed for,
sbt and Scala. This is due to the overrides and excludes present in 0.12.x.
The other possible use of conflictWarning is for general libraries, but
in 0.13 that is better served by using a strict conflict manager. Therefore,
0.13 should drop the warnings based on the evicted modules completely.
Ideally, we wouldn't need to construct the classpath ourselves and instead
reuse the classpath construction code from a compiler (scalac or javac).
However, we need to ensure that we only call the compiler when needed.
Because we need to construct the classpath even when compilation might
not happen, we have to duplicate classpath construction.
This reverts commit 9dd5f076ea which was a revert
itself so we are back to the state before those two reverts.
The problem that caused revert that happened in 9dd5f076ea
has been fixed in 88061dd262.
In `ClassToAPI` both `Private` and `Protected` vals had forward
reference to `Unqualified` so they would get `null` as a result.
Fixed that by rearranging the order of vals being declared.
This fixes a problem described in 9dd5f076ea.
As described in sbt/sbt#676, arguments to `mergeMap` and `merge` methods
were swapped causing wrong structures being created for Java compiled
class files.
This commit fixessbt/sbt#676 and makes pending test to pass now.
Ivy hardcodes the resolution report name in the stylesheet that renders the
HTML from the XML report. This means that the links to other configurations
are broken when using a custom name.
The verbose-level logging is what usually contains relevant information for the user.
Persisting the debug logging slows down update noticeably and clutters the more useful
debug logging output from verbose.
Resolution of https://issues.scala-lang.org/browse/SI-4695 seems to be to deprecate
inheriting from a class in a subpackage. This commit is an alternative solution,
possibly to be reverted or restricted if resolution of SI-4695 changes or if this
proves to be too conservative in practice.
Review by @gkossakowski. With separate inheritance/function call dependency tracking,
this probably should only pull in package objects with inheritance dependencies on
invalidated files.
Mark Harrah
Brendan W. McAdams
Grzegorz Kossakowski
xuwei-k
Anthony