**Problem**
1. query string wasn't passed in, so sonaRelease wasn't working
2. deployment name should be human readable
**Solution**
This fixes the query string passing by hand-crafting the URL.
This also generates human readable deployment name.
**Problem**
Sonatype is sunsetting HTTP Rest endpoint OSSRH in June 2025.
**Solution**
This implements a built-in publishing mechanism.
Kudos to David Doyle who has spearheaded Sonatype Central support via sonatype-central-client etc.
Ensures that `buildTarget/compile` returns a `StatusCode.Error` instead
of a JSON-RPC error even when the compile error is buried deeper in the
`Incomplete` causes.
Fixes#8104
**Problem**
Compiler options for the compiler plugins ends up capturing the absolute path, specific to the machine.
**Solution**
This encodes the plugin paths as virtual paths.
**Problem**
Incremental test (aka testQuick) has a bug when companion objects
depends on others since at some point it's failing to look up relationship from Zinc analysis.
**Solution**
This fixes the lookup.
**Problem**
Incremental test (aka testQuick) has a bug when companion objects
depends on others since at some point it's failing to look up relationship from Zinc analysis.
**Solution**
This fixes the lookup.
**Problem**
sbt 1.10.10 still has retry problem with compilation.
**Solution**
Revert the retry logic back to the time when we only retried IOExceptions.
**Problem**
The error message uses name, which may not match the actual project id
that the user can type into the shell.
**Solution**
Use displayBuildRelative to calculate the proper subproject id.
**Problem**
`run` task has been emulated via function call inside of a sandboxed classloader,
and blocking the command processing of sbt server loop.
This poses isolation and availability issues.
**Solution**
This implements client-side run where the server creates a sandbox environment, and sends the information to the client,
and the client forks a new JVM to perform the run.
The client-side behavior has been implemented in sbtn side already.
**Problem**
When compilation fails, it's retrying 10 times
since Retry now retries on non-IOExceptions.
**Solution**
This adds CompileFailed to excluded exception list.
**Problem**
client-side run apparently won't work for Scala.JS,
so forcing sbtn users to client-side run will break the Scala.JS users.
**Solution**
This reverts the client-side run on sbt 1.x, while retaining the
mechanism for sbt 2.x usages via sbtn.
Now, if `run / connectInput := true` is true, stdout will not display on sbtn.
**Problem**
There are a few places where javaHome or java path is set,
using java.home system property. The problem is that it points to JRE,
not JDK, so it would break on Java compilation etc.
**Solution**
If the path ends with jre, go up one directory.
**Problem**
`run` task blocks the server, but during the run the server is just
waiting for the built program to finish.
**Solution**
This implements client-side run where the server creates a sandbox
environment, and sends the information to the client,
and the client forks a new JVM to perform the run.
**Problem**
semanticdbEnabled doesn't work on sbt 2.x
1. classes directory has changed during compilation
2. semanticdb scalacOptions are duplicated for Test
**Solution**
1. change to using the backend directory
2. reimplement scalacOptions handling
In `classifiersModuleTask` we now don't include the full plugin classpath, but include only the dependency classpath (effectively excluding sbt.PluginData.definitionClasspath). Only items from the dependency classpath are considered to be published. Only for them we can download classifier artifacts later in the `updateSbtClassifiers` pipeline.
This also fixes integration test "dependency-management/update-sbt-classifiers".
I also made the test stricter, it now tests the module ids that are included in the sbt classpath.
**Problem**
We changed the content of Chrome tracing file incorrectly
and renamed tid to tname.
**Solution**
1. This renames tname back to to tid.
2. To retain the fix to avoid Thread#getId, this calls
either the JDK 8 way or the JDK 19 way reflectively.
Add a `allowUnsafeScalaLibUpgrade` setting (default is `false`) to
demote the SIP-51 build failure to a warning.
If the scalaVersion is 2.13.12 but some dependency pulls in
scala-library 2.13.13, the compiler will stay at 2.13.12, but
the dependency classpath will contain scala-library 2.13.13.
This usually works, the compiler can run fine with a newer
scala-library on its dependency classpath.
Macro expansion may fail, if the macro uses some library
class / method that doesn't exist in the old version.
The macro itself is loaded from the dependency classpath
into the class loader running the compiler, where the older
Scala library is on the runtime classpath.
Using the Scala REPL in sbt may also fail in a similar fashion.
**Problem**
Currently sbtn doesn't correctly display the stdout
during `run` because by the time it starts the terminal has been reset.
**Solution**
Don't reset the terminal in-between the tasks.
**Problem**
JSON-RPC is currently full of terminal capability query
since JLine seems to be asking them for each line.
**Solution**
This caches the query.
**Problem**
BOM support current has perf issues.
**Solution**
This bumps Coursier to 2.1.22.
This also adds a new setting `csrMavenDependencyOverride`,
which will default to false.
**Problem**
There are a few places where javaHome or java path is set,
using java.home system property. The problem is that it points to JRE,
not JDK, so it would break on Java compilation etc.
**Solution**
If the path ends with jre, go up one directory.
**Problem**
`java.net.URL` calls out to the network to perform `equals`,
so we should remove that from anywhere that can be involved in caching etc.
**Solution**
This changes java.net.URL to java.net.URI in Keys.
**Problem**
Whether a subproject is root or not is currently detected by
comparing getCanonicalFile against the build base directory.
Problem is that often the root project uses "." as the directory,
and getting the canonical file works ok for the current build,
but it breaks when loading `ProjectRef`.
There might be other bugs related to the root project detection.
**Solution**
This factors out `isRootPath` function that's aware of the build base.
This PR adds the repro test prepared by xuwei-k.
**Problem**
Currently the following warning shows up while compiling metabuild:
[warn] Failed to parse `-Wconf` configuration: cat=unused-nowarn:s
[warn] unknown category: unused-nowarn
-Wconf:cat=unused-nowarn in general was added as a Scala 2.12 of
falsely warning about pure expression not doing anything in the macro.
**Solution**
We should be able to remove the -Wconf flag in sbt 2.x.
**Problem**
Slash syntax is currently implemented via a series of implicit
converters (Conversion), which is not nice, partly because
the behavior is difficult to follow.
**Solution**
This removes all the implicit converters and moves the slashes
into:
1. / methods under Reference for subproject scoping.
2. / methods under ScopeAxis with Reference type constraint
for the initial Zero scoping.
3. Return RefThenConfig structure for intermediate config scoping.
4. / method under `Scoped`, which is base trait for the keys
to implement task scoping e.g. `compile / scalacOptions`.
5. Extension methods for ConfigKey.
6. Extension methods for AttributeKey.
Problem
Currently Scala 3.x - 2.13 sandwich doesn't seem to work for projectMatrix.
This is due to isScala2Scala3Sandwich checking for "3." while projectMatrix
uses scalaBinaryVersion, which is 3.
Solution
This consolidates the implementation of isScala2Scala3Sandwich with the one
in Defaults module, and check for both "3" and "3."
To build the index of all aggregate keys, we were computing the reverse
aggregation of each key, before indexing them.
And so each aggregate key was indexed many times, once for each
aggregated project. It was parallelized to reduce the latency.
In this PR, we compute the reverse aggregation of all the keys at once,
removing all duplication. We cannot parallelize this process anymore
but we don't need to, because it is a lot faster. It reduces the total
CPU time by 12%. The impact for the user depends on its number of cores.
Settings0 used to be a Map[Scope, AttributeMap], and is now a
Map[ScopedKey[x], x].
This is better because we don't need to decompose all ScopedKey[x]
into a Scope and an AttributeKey[x], for recomposing it back later,
which duplicates all ScopedKey[x]. It reduces the number of long-living
ScopedKey[x] by 8%, and the total number of instances by 1.4%.
Also it improves the performance of Settings0, which was responsible of
2.95% of the total CPU time, and is now responsible of 0.41%.
**Problem**
sbt 1.10.0 added support for ++ command with external reference,
but broke ++ takes an aggregate command with slash.
**Solution**
This fixes the parser
The BSP server didn't reset old diagnostic messages sent to BSP clients under
certain circumstances. This commit mitigates this edge case and ensures that
diagnostics for files that previously had compilation problems are properly
reset when fresh diagnostics messages are sent.
The culprit was a mismatch of map keys: Files with problems were sometimes recorded
under an absolute path, but later attempted to be retrieved by virtual path.
This follows on from #7470, to include all sources, not just managed and
unmanaged, in the source jar, along with all resources (previously only
unmanaged resources were included).
This means that if, for whatever crazy reason, someone does modify the
`sources` task to include additional sources or filter out sources, rather than
using the managed or unmanaged source mechanisms, their changes will still be
reflected in the source jar.
**Problem**
1. `or` is missing
2. `?` should have English method name
**Solution**
1. This resurrects `or`
2. Name `??` as `option`, since `get` is taken
**Problem**
I notice that the synthetic root project ends up conflicting with
the projectMatrix on Scala 3, when the name of the matrix
matches the directory name, which is fairly common.
**Solution**
Append `-root` to the root project when there are multiple subprojects found.
**Problem**
It's been a while since Coursier has been the default library management engine,
and we don't need to support two.
**Solution**
This removes `useCoursier` setting.
**Problem**
We want a more flexible way of aggregating subprojects.
**Solution**
This implements a subproject filtering as a replacement of
the subproject axis in the act command.
**Problem**
Since Scala cross building works better than the plugin cross building `^^`,
it was common for plugin authors to encode plugin cross building as Scala cross building
given that we usually have zero or one sbt release in one Scala version.
**Solution**
This brings in the setting into SbtPlugin so plugin authors can cross build
using sbt 2.x.
**Problem**
The new common settings feature doesn't work when the root isn't created by the user.
**Solution**
This fixes common settings by calling `expandCommonSettingsPerBase(...)` on
the synthetic root's base first.
**Problem**
There's been previous attempt like 1878 to skip publishing of the root,
but it seems like the behavior has regressed at some point in time.
**Solution**
This skips publishing on synthetic aggregate root project.
**Problem**
`run` currently blocks all other commands, such as BSP commands.
**Solution**
`run` no longer blocks the command execution loop.
Instead it pauses the prompt on the current command channel.
**Problem**
testQuick currently does not invalidate on argument changes.
**Solution**
This includes test argument digests.
---------
Co-authored-by: adpi2 <adrien.piquerez@gmail.com>
**Problem**
Currently scripted does version checking to block sbt 2.x plugins
to be cross published from sbt 1.x.
**Solution**
Remove the sbt version matching.
**Problem**
During sbt 1.x we created scripted-sbt-redux for package name change.
**Solution**
We can move the module back to scripted-sbt, which simplifies things.
**Problem**
Current implementation of testQuick depends on the concept of timestamp,
which probably won't work well with the new consistent analysis store or
the idea of remote caching.
**Solution**
This is a step towards cached testing by making the incrementality hermetic
(no longer depends on the timestamp). Instead this calculates the aggregated
SHA-256 of the class files involved in the test.
The BSP server didn't reset old diagnostic messages sent to BSP clients under
certain circumstances. This commit mitigates this edge case and ensures that
diagnostics for files that previously had compilation problems are properly
reset when fresh diagnostics messages are sent.
The culprit was a mismatch of map keys: Files with problems were sometimes recorded
under an absolute path, but later attempted to be retrieved by virtual path.
`clean` should delete the packed dir. If it does not,
the next `compileIncremental`, which is a cache hit, will see that
the packed dir is already there and will not unpack it.
This follows on from #7470, to include all sources, not just managed and
unmanaged, in the source jar, along with all resources (previously only
unmanaged resources were included).
This means that if, for whatever crazy reason, someone does modify the
`sources` task to include additional sources or filter out sources, rather than
using the managed or unmanaged source mechanisms, their changes will still be
reflected in the source jar.
See also https://github.com/sbt/zinc/pull/1326
This adds a new setting `enableConsistentCompileAnalysis`,
which enables the new "Consistent" Analysis format,
which is faster and more repeatable than the status quo.
This is initialized to `true` by default.
It can be opted out either by the setting or using
`-Dsbt.analysis2024=false`.
When loading a scripted test, sbt creates a jar file and loads it.
The path of the jar file is the same for all the batched tests.
We must prevent the JDK from caching this jar file to force a reload after each test.
Otherwise sbt tries to load the auto-plugins of a previous test and fails.
When a macro was compiled against a new scala-library (say 2.13.15),
the runtime classpath of the Scala compiler should not contain an older
scala-library. Otherwise the macro can cause a NoSuchMethodException
during expansion.
This commit updates scala-library in the scalaInstance to the version
on the projects dependency classpath.
The `csrSameVersions` setting can be used to keep dependencies at the
same version.
By default it's used for Scala artifacts. They need to be kept at the
same version because the compiler / reflect are built with
cross-artifact inlining enabled.
`csrSameVersions := Seq(Set(scala-library, scala-reflect, scala-compiler, scalap))`
Users can make use of the new setting in the following way:
- `csrSameVersions += Set[InclExclRule]("com.corp" % "lib", "com.corp" % "lub")`
- `csrSameVersions += Set[InclExclRule]("com.corp" % "lib-family-*")`
When expanding a macro compiled against a new Scala library, the
runtime classpath of the compiler should not contain an older library.
Otherwise a NoSuchMethodException can occur.
A similar issue is present when running the Scala repl through sbt.
An input line compiled against a new library could fail to run if
the repl's runtime classpath is on an old version.
There are a couple of settings / configs that affect this, summary
below. The change in this PR seems to be the most narrow.
`scalaModuleInfo.value.overrideScalaVersion` in sbt
- affects how sbt to sets coursier's `forceScalaVersion` (see below)
- used by librarymanagement.ivy. If true, add a OverrideScalaMediator
See sbt/sbt#2634. Probably not relevant when using coursier.
`autoScalaLibrary` setting in sbt
- automatically add `scala-library` (or `scala3-library`) as a project
dependency
- also used for `forceScalaVersion` (see below)
`CoursierConfiguration.autoScalaLibrary`
- if `true` then Coursier `ResolutionParams.forceScalaVersion` is set
to to `true`
- initialized by sbt to
`autoScalaLibrary.value &&
!ScalaArtifacts.isScala3(sv) &&
!Classpaths.isScala213(sv) && // added in this commit
scalaModuleInfo.forall(_.overrideScalaVersion)`
coursier `ResolutionParams.forceScalaVersion`
- if true, `scala-library` / `scala-reflect` / `scala-compiler` /
`scalap` are forced to the scala version, not actually resolved
- for Scala 3, the `scala3-library` and `scala3-compiler` versions
are forced
For the details about this PR, please see the blog post https://eed3si9n.com/sbt-remote-cache/.
* Add cache basics
* Refactor Attributed to use StringAttributeMap, which is Map[StringAttributeKey, String]
* Implement disk cache
* Rename Package to Pkg
* Virtualize packageBin
* Use HashedVirtualFileRef for packageBin
* Virtualize compile task
Previously, in sbt 2, the Scripted plugin was not resolving any module
that would provide it with the `ScriptedTests` object, and could
therefore not run scripted tests.
With this patch, `scripted-sbt-redux` will be resolved and added to the
classloader that's used to load `sbt.scriptedtest.ScriptedTests`.
Eugene Yokota
kenji yoshida
Alec Theriault
Brice Jaglin
Adrien Piquerez
Dmitrii Naumenko
Josh Soref
Lukas Rytz
Derek Wickern
friendseeker
Matthew de Detrich
philippus
SlowBrainDude
James Roper
Seth Tisue
Martin Duhem
Tammo Steffens