The compiler bridge dependency resolution had `missingOk = true` flag on. This would silently succeed even when one of the dependency is missing, and it would randomly fail bridge compilation, which is very confusing.
This commit addresses several concers:
* Document better the Zinc internal implementation.
* Getting the implementation ready for moving things from internal to
public APIs. This will be done in a follow-up commit.
* Removing `inputs` and `setups` from the `IncrementalCompilerUtil` as
they exist mainly to interface between Scala code and Java code. The
reality is that both Java and Scala developers can easily call the
constructors by themselves and don't learn more API methods.
* Removes unused imports, that emit stupid warnings.
* Make code more readable, especifically in the analyzing compilers for
both Java and Scala, which was hardly understandable and documented.
* Make `AnalyzingJavaCompiler` to extend `JavaCompiler` as
`AnalyzingCompiler` does for `ScalaCompiler`. In an upcoming commit,
`AnalyzingCompiler` will be renamed into `AnalyzingScalaCompiler` for
consistency reasons.
* Replace use of `sbt.util.Logger` helpers by `sbt.util.InterfaceUtil`.
This migrates the `ComponentManager` from librarymanagement, and refactors it to clarify the double caching of the compiler bridge.
The main purpose of this refactoring is to fixsbt/sbt#2539. As it stands, becaue Ivy cache directory is being used as the secondary cache of the compiled compiler bridge, it's annoying to work with the compiler bridge. Instead of using "Ivy cache", the new `ZincComponentManager` accepts `secondaryCacheDir: Option[File]`, which during test defaults to `target/zinc-components`.
Fixessbt/sbt#2539
The compiler bridge had a dependency on the scala compiler in the
version defined in the build definition. This means that when trying to
fetch the compiler bridge for, say, Scala 2.9.2, we would also pull in
the Scala compiler 2.10.5.
The compiler bridge now has a "provided" dependency on the Scala
compiler.
Previously the component compiler depended on a `componentID` added to
some interfaces to be able to compile the compiler interface. sbt's
launcher placed artifacts marked with this `componentID` in a special
directory that was then used by the ComponentCompiler to be able to
compile the compiler interface.
This commit modifies the ComponentCompiler so that it does not expect
these components to be already present in some directory, but instead
downloads it using Ivy when required.
This will avoid all clashes between modules that may have the same name
as other components of sbt, or two different compiler bridges that would
happen to have the same name.
Note that they won't be downloaded again, because the component compiler
will look for a previously-compiled version of the compiler bridge
before trying to fetch the sources again. If they've already been
downlaoded, then they have been compiled and a compiled version of the
compiler bridge already exists.
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
Previously we used the version of the component manager. However, these
two versions do not need to be in sync, which would make us try to
retrieve the wrong version of the compiler interface sources.
Because in most cases there aren't version-specific sources, we expect
the retrieval to fail a number of times before succeeding. This
generates a lot of noise in sbt's log, so the logs will now be shown if
and only all the versions fail.
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.
Eugene Yokota
jvican
Dale Wijnand
Simon Schäfer
Martin Duhem
Grzegorz Kossakowski
Pierre DAL-PRA
Mark Harrah