* 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.
Ref https://github.com/sbt/sbt/issues/4583
This moves the super shell rendering to ConsoleAppender with several improvements.
Instead of scrolling up, supershell is now changed to normal scrolling down, with more traditional cursor position. Before printing out the logs, last known progress reports are wiped out. In addition, there's now 5 lines of blank lines to accomodate for `println(...)` by tasks.
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.
Prior to this commit, it was difficult to prevent the sbt metabuild
classpath from leaking into the runtime and test classpaths. The biggest
issue is that the test-inferface jar was located in the metabuild
classpath. We tried to prevent leakage using the DualClassLoader, but
this was an ugly solution that did not seem to work reliably. The fix is
to modify the actual sbt metabuild classloader provided by the sbt
launcher.
To do this, I add a new classloader SbtMetaClassLoader that isolates the
test-interface jar from the rest of the classpath. I modify xMain to
create a new AppConfiguration that uses this new classloader and
use reflection to invoke the sbt main method using the new classloader.
Not only do I think that this is a much saner solution than DualLoaders,
I accidentally fixed#4575 with this change.
It isn't possible to share the runtime and test layers correctly with
bgCopyClasspath is used because the runtime classpath uses the
dependencies copied to the boot directory while the test classpath uses
the classes in target and .ivy2. Since this is not the default and users
have to opt in to
ClassLoaderLayeringStrategy.ShareRuntimeDependenciesLayerWithTestDependencies,
I think this is fine.
It is possible with the new layering strategies that tests may fail if a
java package private class is accessed across classloader layers. This
will result in an IllegalAccessError that is hard to debug. With this
commit, I add an error message that will be displayed if run throws an
IllegalAccessError that suggests that the user try the
ScalaInstance layering strategy or the flat layering strategy.
Eugene Yokota
Dale Wijnand
Helena Edelson
Dale Wijnand
Ethan Atkins
Ethan Atkins