Consider a configuration where we have two projects, A and B.
A has a library dependency on "a" % "b" % "1.0.0" % "compile->runtime"
and "a" % "b" % "1.0.0" % "compile->runtime2"
B depends on project A, and has a library dependency on
"a" % "b" % "1.0.1" % "compile->runtime".
Note that project B depends on a more recent version of "a" % "b" than
project A, and that it depends ONLY on it's "runtime" configuration.
However, when compiling project B, we expect to have on the classpath
project A, and "a" % "b" % "1.0.1" % "compile->runtime" AND
"a" % "b" % "1.0.1" % "compile->runtime2" because it is part of the
compile configuration of project A.
This commit changes the cached resolution engine so that it behaves like
that, by first resolving dependencies on other project and then ensuring
that the dependent project specifies dependencies on the same
configurations.
Mark test dependency-management/cached-resolution-configurations as
passing.
When concatenating the artifacts coming from two modules, we sometimes
attempted to create a default artifact from the organization and name of
the module.
However, this may fail because a module a % b "1.0" may not have an
artifact named "b.jar" (see sbt/sbt#2431).
Fixessbt/sbt#2431.
This is a combination of 13 commits. I squashed these 13 commits to make
forward porting those changes easier, since some commit undo the changes
of other commits.
The PRs that include these changes can be found at
https://github.com/sbt/sbt/pull/2564 and
https://github.com/sbt/sbt/pull/2576.
Static launcher, get bridge sources from resources
This commit introduces a new "static" launcher that does not use Ivy to
gather all the artifacts that it requires, but rather expect them to be
immediately available.
To be able to use sbt without Internet access, we add a new
`ComponentCompiler` that is able to retrieve the bridge sources from the
resources on classpath and compile it.
Fix classpath issues in static launcher
The launcher defines a top classloader that willbe used by all
`ScalaInstance`s. Previously, this top classloader had a parent that
contained the scala library 2.10, which prevented the correct
compilation of the compiler bridge for scala 2.11.
Also, we no longer need the scala-reflect JAR.
Tests for FakeResolver
Add `scala-reflect.jar` to JARs of `StaticScalaProvider`
It turns out we need to have `scala-reflect.jar` on classpath to compile
the compiler bridge for the static scala instance of the launcher.
Comply to Ivy's specification in `FakeResolver`
Remove `CompilerBridgeProvider` and `ResourceBridgeProvider`
It turns out that we can leverage the`FakeResolver` that has been
implemented to use with the static launcher, and resolve a "fake
compiler bridge" using it, rather than copying it from the resources.
This also has the advantage of not requiring to change the build
definition.
Fix NPE in FakeResolver
Add compiler bridge sources to fake resolver
This allows sbt to resolve the compiler bridge sources when using the
static launcher
Don't hardcode sbt version in static launcher
Add scala compiler and library to fake resolver
This allows us to still resolve them if we have no other resolver
configured.
Add `RepositoriesParser`
This parser is used by the static launcher to parse the definition of
resolvers that override the build resolvers.
Support repositories override in static launcher
The static launcher will now parse user-defined repositories like the
usual launcher does.
Specifically, the static launcher now uses the following configuration:
- `sbt.boot.directory`: specifies the boot directory that sbt will use.
Defaults to `~/.sbt/boot`.
- `sbt.override.build.repos`: indicate whether we want to override the
build resolvers. Defaults to false.
- `sbt.repository.config`: specifies the path to the files that
contains repositories definition. Defaults to
`${sbt.boot.directory}/repositories`.
Notes for sbt/sbt#2564 & sbt/sbt#2576
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 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`.
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)
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.
eugene yokota
Miles Sabin
Martin Duhem
ddworak
João Costa
Dan Sanduleac
Dale Wijnand