* Create a project "common" which publishes a "bad" artifact.
* Resolve project "dependent" which resolves the "bad" artifact into the cache.
* Publish a new "common" snapshot to a diffferent repository (publishLocal)
* Attempt to build the new project, leading to issues.
Commit a1e26ca6 broke the `make-pom` & `pom-advanced` dependency-management
tests by replacing one reference to `IBiblioResolver.DEFAULT_M2_ROOT` in
`Resolver`, but not the other reference in `MakePom`:
https://travis-ci.org/sbt/sbt/jobs/31939788#L2517-L2519
...the secure url was no longer recognised as the default Maven Repository
root, so was erroneously exported.
When the compiler reports back the error to CompilationUnit created by Eval#mkUnit, it sometimes returns OffsetPosition whose `source` is set to `NoSourceFile`.
This causes ArrayIndexOutOfBoundsException. The current workaround is to pattern match on the passed in pos and create a new one when the incoming source looks suspicious.
I have not figured out whether this is caused by our macro code or compiler.
There are various build.sbt errors that would cause this behavior:
```scala
libraryDependencies ++= Seq(
depA
depB // missing comma
)
lazy val bob = scala.Console println
test ++
run+
```
Scope.parseScopedKey now supports full range of legal keys
described in the documentation including {.} and other
notation for ProjectRef, BuildRef, and ThisBuild.
UnresolvedWarning is moved back to IvyActions.scala where it belongs.
The mapping between ModuleID and SourcePosition is passed in as UnresolvedWarningConfiguration.
This is calculated once in Defaults using State and is cached to filesystem.
Unresolved dependency warning is moved to UnresolvedDependencyWarning class including
the fail path that was added in #1467.
To display the source position, I need to access the State, so I had to move the
error processing out of IvyActions and add UnresolvedDependencyWarning, which is
aware of State.
* Ensure the ++ command stores its changes on the sbt session.
* Make sure `session clear-all` will clear out ++ changes
* Validate that `set` command doesn't undo `++` changes
Note: There is some autogenerated Setting[_] delegate optimisation
work that could be done in the future.
* Migrate weak reference into logger class so we can test clearing it.
* Ensure new state.log is propoagted into settings on `set` command.
* Fix set test so that it ensures the sLog is relatively stable when
reloading on set command.
Eugene Yokota
Roberto Tyley
Josh Suereth
Jacek Laskowski
Evgeny Goldin