This addresses 0.13.10 regression, which currently warns users about
Maven incompatibility on a private configuration. This adds a config
class so the build user can control the level of the warning as well as
the target configuration to be monitored.
By default, we are only going to look at `Compile` and `Runtime`.
Previously, the autoimports for globally defined plugins were not
imported for global configuration files, although they were imported for
project configuration files.
This patch causes an additional plugin discovery phase to happen during
global config evaluation, so that auto-plugins can be detected and their
imports subsequently included.
Tested manually:
$ grep 'version.*:=' build.sbt
version := "0.13.10-SNAPSHOT",
$ git archive --prefix=sbt-0.13.10-SNAPSHOT/ -o ~/Desktop/sbt-0.13.10-SNAPSHOT.tgz HEAD
$ cd ~/Desktop
$ ls
sbt-0.13.10-SNAPSHOT.tgz
$ tar xfz sbt-0.13.10-SNAPSHOT.tgz
$ cd sbt-0.13.10-SNAPSHOT/
$ sbt info
[info] Loading global plugins from /Users/dnw/.dotfiles/.sbt/0.13/plugins
[info] Loading project definition from /Users/dnw/Desktop/sbt-0.13.10-SNAPSHOT/project
[info] Updating {file:/Users/dnw/Desktop/sbt-0.13.10-SNAPSHOT/project/}sbt-0-13-10-snapshot-build...
[info] Resolving org.fusesource.jansi#jansi;1.4 ...
[info] Done updating.
[warn] There may be incompatibilities among your library dependencies.
[warn] Here are some of the libraries that were evicted:
[warn] * com.typesafe.sbt:sbt-site:0.8.1 -> 0.8.2
[warn] Run 'evicted' to see detailed eviction warnings
[info] Compiling 12 Scala sources to /Users/dnw/Desktop/sbt-0.13.10-SNAPSHOT/project/target/scala-2.10/sbt-0.13/classes...
[info] This is sbt 0.13.9
[info] The current project is {file:/Users/dnw/Desktop/sbt-0.13.10-SNAPSHOT/}sbtRoot 0.13.10-SNAPSHOT
[info] The current project is built against Scala 2.10.6
[info] Available Plugins: sbt.plugins.IvyPlugin, sbt.plugins.JvmPlugin, sbt.plugins.CorePlugin...
[info] sbt, sbt plugins, and build definitions are using Scala 2.10.5
Adds `trackInternalDependencies` and `exportToInternal` settings. These
can be used to control whether to trigger compilation of a dependent
subprojects when you call `compile`. Both keys will take one of three
values: `TrackLevel.NoTracking`, `TrackLevel.TrackIfMissing`, and
`TrackLevel.TrackAlways`. By default they are both set to
`TrackLevel.TrackAlways`.
When `trackInternalDependencies` is set to `TrackLevel.TrackIfMissing`,
sbt will no longer try to compile internal (inter-project) dependencies
automatically, unless there are no `*.class` files (or JAR file when
`exportJars` is `true`) in the output directory. When the setting is
set to `TrackLevel.NoTracking`, the compilation of internal
dependencies will be skipped. Note that the classpath will still be
appended, and dependency graph will still show them as dependencies.
The motivation is to save the I/O overhead of checking for the changes
on a build with many subprojects during development. Here's how to set
all subprojects to `TrackIfMissing`.
lazy val root = (project in file(".")).
aggregate(....).
settings(
inThisBuild(Seq(
trackInternalDependencies := TrackLevel.TrackIfMissing,
exportJars := true
))
)
The `exportToInternal` setting allows the dependee subprojects to opt
out of the internal tracking, which might be useful if you want to
track most subprojects except for a few. The intersection of the
`trackInternalDependencies` and `exportToInternal` settings will be
used to determine the actual track level. Here's an example to opt-out
one project:
lazy val dontTrackMe = (project in file("dontTrackMe")).
settings(
exportToInternal := TrackLevel.NoTracking
)
This is a fixup of 0f616294c4.
That commit assumed that dealiasing is being done for types referred in
self type. It was changed to not do that but the test wasn't updated.
Unfortunately, that mistake slipped by during PR review because unit tests
of compileInterface were not ran (see #2358).
Further categorize debug output as api diff ([diff]), and
invalidation ([inv]). Since we log a ton of diagnostics,
make it a bit easier to find the relevant bits.
Since pickled annotated types and symbols only mention
static annotations, whereas compilation from source
sees all annotations, we must explicitly filter annotations
in the API representation using the same criteria as the pickler,
so that we generate the same API when compiling from source
as when we're loading classfiles.
Also a bit more complete: handle SelectFromTypeTree,
consider the self type an inheritance dependency,
and flatten any refinement types in inherited types,
to get to the symbols of their parents, instead of the
useless symbol of the refinement class.
Include inheritance dependencies in regular ones
Also, update test to reflect the self type is now seen as an inheritance dependency.
self types are local, so don't treat them like inherited types
note inheritanceSymbols dealiases, where allSymbols is constructed differently
fix NPE in source-dependencies/macro-annotation
Specialize two implementations for each value of the `inherit` boolean argument.
Also use a more direct way of distinguishing declared and inherited members.
backwards compat for source-dependencies/inherited-dependencies
For refinement types, the Structure was already restricted
to declarations (and not inherited members), but all base types
were still included for a refinement's parents, which would
create unwieldy, and even erroneous (cyclic) types by expanding
all constituents of an intersection type to add all base types.
Since the logic already disregarded inherited members, it seems
logical to only include direct parents, and not all ancestor types.
```
class Dep {
def bla(c: Boolean) = if (c) new Value else "bla"
}
class Value extends java.lang.Comparable[Value] { def compareTo(that: Value): Int = 1 }
```
Motivated because we want to make it more robust & configurable.
Original motivation was to diagnose a cyclic type representation,
likely due to an f-bounded existential type, as illustrated by the following:
```
class Dep {
// The API representation for `bla`'s result type contains a cycle
// (an existential's type variable's bound is the existential type itself)
// This results in a stack overflow while showing the API diff.
// Note that the actual result type in the compiler is not cyclic
// (the f-bounded existential for Comparable is truncated)
def bla(c: Boolean) = if (c) new Value else "bla"
}
class Value extends java.lang.Comparable[Value] { def compareTo(that: Value): Int = 1 }
```
Limit nesting (`-Dsbt.inc.apidiff.depth=N`, where N defaults to `2`),
and number of declarations shown for a class/structural type
(via `sbt.inc.apidiff.decls`, which defaults to `0` -- no limit).
Limiting nesting is crucial in keeping the size of api diffs of large programs
within a reasonable amount of RAM...
For example, compiling the Scala library, the API diff with nesting at `4`
exhausts 4G of RAM...
The only aspect of the self variable that's relevant for
incremental compilation is its explicitly declared type,
and only when it's different from the type of the class that declares it.
Technically, any self type that's a super type of the class could be ignored,
as it cannot affect external use (instantiation/subclassing) of the class.
Call `initialize` in case symbol's `info` hadn't been completed
during normal compilation.
Also, normalize to the class symbol immediately.
Add a TODO regarding only looking at class symbols,
and thus ignoring the term symbol for objects,
as the corresponding class symbol has all the relevant info.
Both continuations and macro-config set scalaVersion explicitly but since
sbt relies now on Scala 2.10 it's not needed anymore. In particular, we
can upgrade continuations to 2.10 which makes it easier to work with Java
8.
withInterProjectFirst when set to true will prioritize inter-project
resolver over all other resolver and Ivy cache.
This aimed to workaround the fact that on Maven Test configuration is
considered private, and thus project dependency with `test->test`
configuration may not under some condition. The condition is when
someone resolves `x:y:1.0` and you have a subproject named and
versioned exactly that, and some other subproject tries to depend on
it. This happens when the project does not change the version number on
the Github.
Include sbt-ivy-snapshots to launchconfig
Prior to this change, the launchconfig for sbt was generated using
Transform's resource generator so releases would include
`typesafe-ivy-releases` repo, and snapshot releases would include
`typesafe-ivy-snapshots` and `sonatype-snapshots` repos in addition.
This is no longer useful since nightly builds are now published to
`sbt-ivy-snapshots` instead, which is backed by Bintray.
This removes the switching logic, so both `typesafe-ivy-releases` and
`sbt-ivy-snapshots` repos are always included into the launchconfig.
This removes the step of needing to download a launcher just to try the
nightly builds.
eugene yokota
Dale Wijnand
Tim Harper
Grzegorz Kossakowski
Adriaan Moors
Krzysztof Romanowski
Guillaume Martres