mirror of https://github.com/sbt/sbt.git
146afdf8cd
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. |
||
|---|---|---|
| internal/zinc-ivy-integration/src | ||