This adds dependency to LM implemented using Coursier.
I had to copy paste a bunch of code from sbt-coursier-shared to break the dependency to sbt.
`Global / useCoursier := false` or `-Dsbt.coursier=false` be used to opt-out of using Coursier for the dependency resolution.
I discovered that it wasn't possible to call .previous in an input task.
While I understand why you can't call .previous on an InputKey, I think
it makes sense to allow calling .previous on a TaskKey within an input
task.
* zinc-lm-intergration/bring-back-a-piece-of-zinc: (90 commits)
Add scala-integration resolver
call it compiler-bridge_2.13
bump Scala bridge to use 2.13.0-RC1
Break the dependency on LM, and thus Ivy
Skip Scala 2.10 and Scala 2.11 components for JDK 11
Refactor compiler bridge unit test
Fix the several typos detected by github.com/client9/misspell
Got rid of multiple warnigns
include only scala-library into the boot classpath during run
Drop "final" modifier from private case classes, to prevent false positive. Refer https://issues.scala-lang.org/browse/SI-4440
Support scala 2.13.0-pre-* & 2.13.0-M1
Split compiler bridge tests to another subproject
Remove unused imports + variables
Add back, re-configure & re-enable Scalafmt
Use Scala 2.12.3
Remove any reference to `F0` and `F1`
Adapt Zinc to use the new LibraryManagement API
Fix ScalaFmt wiring
Add scalaCompiler variant that accepts ModuleID
Bump all the modules
...
Fixes#4438
This slims down update's UpdateReport by removing evicted modules
caller information. The larger the graph, the effect would be more
pronounced. For example, I saw a graph reduce from 5.9MB to 1.1MB in JSON file.
We are fairly certain we can maintain source-compatibility of compiler bridge from 2.13.0-RC to 2.13.x.
See also https://github.com/sbt/zinc/issues/78 :)
* 1.2.x: (28 commits)
More bumping up the 2.12 version to 2.12.8 in 1.2.x
Bump the 2.12 version to 2.12.8 in 1.2.x
define whitesourceOnPush
lm 1.2.4
1.2.7-SNAPSHOT
implement TestConsoleLogger
bump util, lm, and zinc
Bump scalatest to 3.0.6-SNAP5
Bump log4j2 to 2.11.1
drop notification override
Ignore files in scripted group dirs
Fix '~' for dependent projects with a broken parent
util 1.2.3, zinc 1.2.4
lm 1.2.2
Adjust the tests
Set withMetadataDirectory by default
Fix single repo emulation script
add onLoadMessage
check PluginCross.scala consisntency
Bump modules
...
This patch breaks the dependency that Zinc had on sbt's Library
Management (LM) library abstraction (sbt/librarymanagement) and thus,
transitively, on Ivy.
The reason Zinc depends on LM in the first place is to dynamically
download the compiler bridge sources JAR, which it then compiles in
order to bridge from binary-compatible Zinc to the never-binary-stable
(and most of the time source-compatible) compiler API.
From my research (that is, using GitHub Search) the only user of this
feature is sbt, with all other integrations (e.g. pants, bloop, mill)
providing the compiler bridge sources JAR directly (an alternative API
entry point).
Therefore the dependency on LM and that integration code could be
untangled from Zinc and moved into sbt. That would also give an
opportunity to move the code in LM (back) into sbt, which I also think
would be a good idea.
For now this patch leaves that integration code in the already existing
`zinc-ivy-integration` module, but which is now no longer a dependency
of any other module of Zinc, specifically it is no longer a dependency
of the `zinc` and `zincScripted` modules. I think, though,
zinc-ivy-integration should remain in the zinc repo, as a part of the
build, being tested in CI, until it's been moved (back) into sbt. I'd
be happy to take care of both the remaining move and removal tasks.
In order to allow removing LM, Ivy and zinc-ivy-integration as
transitive dependencies of Zinc, this patch has to make a breaking
change to the `ZincUtil` object in the zinc module. Despite it being
defined in the `sbt.internal.inc` package (i.e. not declared as public
API) ZincUtil is in fact a used (Scala) API of Zinc (usages discovered
via GitHub Search). Therefore I chose to leave the object in the zinc
module and only drop from the object the two methods that directly
depend on LM's API. Specifically (1) the `getDefaultBridgeModule`
method and (2) the `scalaCompiler` overload that depends on LM were
removed. These methods now live in a new `ZincLmUtil` object in
zinc-ivy-integration, which sbt can switch to using.
In terms of risk, from my research (GitHub Search) the only users of
those methods are sbt and bloop. I need to confirm but I think bloop
will be able to manage this breaking change (it looks it might be just
fallback usage? TBC). For sbt we don't actual support using new Zinc
with old sbt, so sbt can also just update its usage on its next release.
Any other usage risks being broken but given it's internal, non-public
API I think it's fair game.
The remaining changes are in the testing so that zinc-ivy-integration's
test suite continues to test its download-and-compile behaviour, while
the rest of Zinc switches to using the prebuilt compiler bridges,
reusing and generalising some pre-existing zincScripted code (as well as
re-wiring some modules) so it can be used by zinc's tests too.
It was reported in https://github.com/sbt/sbt/issues/4608 that there was
a regression that tests run against scala 2.11 would fail. This was
because the interface loader incorrectly contained the scala library. To
fix this, I needed to find the xsbt.boot.BootFilteredLoader in the
classloading hierarchy and put the sbt testing interface library in
between that loader and the scala library loader.
We noticed that the community build was failing for some projects due to
some class loading issues. My initial approach for detecting the errors
didn't always work because the test framework might wrap the underlying
exception. To fix that, I add the causes to the list of throwables to
scan for class loading related exceptions. I also added
ClassNotFoundException to the list of types to check for. I additionally
added more context to the error message so that it is more clear to the
user what specifically went wrong. The error message is intended to
provide examples that the user can actually paste into the console.
There is also a lot of manual line wrapping that could be improved by
defining paragraphs and then splitting on the jline terminal width. That
could be a useful internal helper function to improve our log messages
in general.
The underlying issue could be addressed by allowing the user to specify
libraries that get excluded from the dependency classpath for layering
purposes. I'm not sure the best way to do that yet and adding that
feature wouldn't fix any existing builds so I think that would be better
handled in 1.4.0.
Eugene Yokota
Ethan Atkins
Dale Wijnand
Helena Edelson
Dale Wijnand
Ethan Atkins