Skip to content

Update sbt to 2.0.0 #488

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
scala-steward wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Update sbt to 2.0.0 #488

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion project/build.properties
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1 +1 @@
sbt.version=1.12.12
sbt.version=2.0.0

@coderabbitai coderabbitai Bot Jun 16, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🔴 Critical

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# Description: Verify sbt plugin compatibility with sbt 2.0.0

# Test: Check if plugins in project/plugins.sbt declare sbt 2.0.0 support
rg -A 5 'addSbtPlugin' project/plugins.sbt

# Test: Search codebase for references to sbt 1.x specific APIs or syntax (e.g., ThisBuild, old scoping syntax)
echo "=== Checking for potential sbt 1.x specific patterns ==="
rg 'ThisBuild|inThisBuild|in ThisBuild' --type scala || echo "No ThisBuild references found"

# Test: Check for .sbt files that might use old 0.13 syntax (curly-brace syntax)
echo "=== Checking for potential sbt 0.13 syntax ==="
find . -name '*.sbt' -exec grep -l '{' {} \; | head -5 || echo "No potential 0.13 syntax found"

Repository: nafg/slick-migration-api

Length of output: 492

🏁 Script executed:

# Check the content of ci.sbt to see what syntax is used
cat -n ci.sbt

Repository: nafg/slick-migration-api

Length of output: 1844

🏁 Script executed:

# Check the content of build.sbt to understand the inThisBuild usage
head -30 build.sbt

Repository: nafg/slick-migration-api

Length of output: 1403

🌐 Web query:

sbt-scoverage 2.4.4 sbt 2.0.0 compatibility

💡 Result:

Yes, sbt-scoverage version 2.4.4 is compatible with sbt 2.0.0 [1]. The official Scala Index explicitly lists compatibility for sbt-scoverage 2.4.4 with sbt 2.x [1]. The plugin is distributed with cross-build support for sbt 2.0.0, and you can add it to your project's plugins by using the standard plugin dependency declaration: addSbtPlugin("org.scoverage" % "sbt-scoverage" % "2.4.4") Historical releases of sbt-scoverage had been adding support for sbt 2.0.0 milestone and release candidate versions leading up to the final sbt 2.0.0 release [2], confirming a managed transition to support the latest major version of sbt.

Citations:

🌐 Web query:

sbt-coveralls 1.3.15 sbt 2.0 compatibility

💡 Result:

As of June 2026, sbt-coveralls version 1.3.15 is not natively compatible with sbt 2.0. Sbt 2.0 introduced significant breaking changes, including a new plugin publishing format (using the _sbt2_3 suffix) and a move to Scala 3.x for build definitions [1]. Current metadata for sbt-coveralls 1.3.15 indicates it is published for sbt 1.x [2], and there is no evidence of an sbt 2.0-specific release for this plugin. While the related plugin sbt-scoverage has actively incorporated support for sbt 2.0 (e.g., versions starting from 2.4.x) [3][4], sbt-coveralls remains at version 1.3.15, last updated in January 2025 [5][6]. Users attempting to use sbt-coveralls in an sbt 2.0 build environment will likely encounter compatibility errors due to these structural changes in the sbt plugin ecosystem [1].

Citations:

🌐 Web query:

sbt-ci-release 1.11.2 sbt 2.0 compatibility

💡 Result:

sbt-ci-release version 1.11.2 is fully compatible with sbt 2.x [1][2]. The plugin is cross-published to support both sbt 1.x and sbt 2.x ecosystems [1][3]. When using version 1.11.2, you can use the standard dependency declaration in your project: addSbtPlugin("com.github.sbt" % "sbt-ci-release" % "1.11.2") [2] The plugin maintains support for both major versions, which is particularly useful for projects performing migrations or back-publishing during the sbt 2.x transition [4][5]. Additionally, sbt-ci-release 1.11.x and later includes support for the Central Portal publishing requirements, which are necessary for modern sbt releases [4][6].

Citations:

🌐 Web query:

sbt 2.x inThisBuild API removed breaking change

💡 Result:

In sbt 2.x, the use of ThisBuild scoping for global settings has been fundamentally changed to support a new "common settings" model [1][2]. While the inThisBuild API itself has not been simply "removed" as a breaking syntax in the same way deprecated methods are, the architectural approach to build configuration has shifted, rendering the manual use of ThisBuild for basic settings unnecessary and discouraged [1][2]. Key details regarding this change: 1. Common Settings Model: In sbt 2.x, bare settings defined in build.sbt are automatically interpreted as "common settings" and injected into all subprojects [1]. This replaces the previous role of ThisBuild, which was commonly used in sbt 1.x to apply settings globally [1][2]. 2. Migration Impact: Because these common settings are now injected between plugin settings and those defined in settings(...), they provide more predictable delegation [2]. You no longer need to use the ThisBuild / key:= value syntax for settings like scalaVersion [1]. 3. Delegation and Scoping: This change simplifies build definitions by eliminating the need to explicitly scope settings to ThisBuild to ensure they are shared across subprojects [1][3]. 4. Related Removals: Note that sbt 2.x does include other breaking changes related to older sbt syntax, such as the removal of legacy sbt 0.13 style build.sbt "in" methods (e.g., scalacOptions in (Compile, console)), which should be migrated to the unified slash (/) syntax [4]. For users upgrading, the official recommendation is to adopt the new common settings model by removing explicit ThisBuild scopes for standard project-level settings [2]. This makes builds more predictable and reduces the complexity associated with manual scoping [2].

Citations:

🌐 Web query:

sbt-mergify-github-actions 0.9.0 sbt 2.0 compatibility

💡 Result:

As of June 16, 2026, version 0.9.0 of sbt-mergify-github-actions does not explicitly claim compatibility with sbt 2.0 [1][2]. Released on September 26, 2024, version 0.9.0 predates the broader adoption of sbt 2.0 [1]. While sbt-mergify-github-actions depends on the sbt-github-actions plugin, which has seen updates to support sbt 2.0 [3], there is no indication that sbt-mergify-github-actions has been updated or released to specifically accommodate the changes introduced in sbt 2.0 [1][2]. If you are migrating to sbt 2.0, you may encounter compatibility issues or require a newer release of the plugin, should one become available, to support the new sbt 2.0 architecture.

Citations:

🌐 Web query:

sbt 2.0 exportJars default true breaking change getResource

💡 Result:

In sbt 2.0, the exportJars setting now defaults to true, whereas it defaulted to false in previous versions [1][2]. This change means that sbt now uses the packaged JAR file on the classpath instead of the directory containing raw class files and resources [3][4]. This shift can cause issues with code that relies on accessing resources directly from the filesystem (e.g., via getResource("/") or resource.toURI), as these methods may fail with NullPointerException or FileSystemNotFoundException when the resources are inside a JAR file rather than a directory [1][2]. If your build logic is negatively impacted by this change, you can restore the previous behavior by explicitly setting the following in your build definition: exportJars:= false This setting is recommended as a workaround if you encounter compatibility issues, such as those reported with certain plugins or test utilities that assume a directory-based classpath structure [1][2][5].

Citations:

🏁 Script executed:

# Check if project uses getResource or exportJars explicitly
rg -i 'getresource|exportjars' --type scala --type sbt

Repository: nafg/slick-migration-api

Length of output: 96

Resolve sbt plugin incompatibility before upgrading to sbt 2.0.0.

sbt-coveralls 1.3.15 is not compatible with sbt 2.0.0 (remains sbt 1.x only with no sbt 2.0 release). Additionally, sbt-mergify-github-actions 0.9.0 lacks explicit sbt 2.0 support. Both plugins will fail under sbt 2.0.0.

sbt-scoverage 2.4.4 and sbt-ci-release 1.11.2 are compatible with sbt 2.x.

Update or replace the incompatible plugins with sbt 2.0-compatible versions before merging this change. Alternatively, revert to sbt 1.12.12 and wait for downstream plugin releases.

🤖 Prompt for AI Agents 
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@project/build.properties` at line 1, The sbt version upgrade to 2.0.0 in
build.properties is incompatible with two plugins in the project's build
configuration: sbt-coveralls 1.3.15 is sbt 1.x-only with no sbt 2.0 release, and
sbt-mergify-github-actions 0.9.0 lacks explicit sbt 2.0 support. Before merging
this change, locate and update these plugin versions in the build configuration
(likely in project/plugins.sbt or similar) to sbt 2.0-compatible versions, or
replace them with compatible alternatives. The sbt-scoverage 2.4.4 and
sbt-ci-release 1.11.2 plugins are already compatible and require no changes. If
compatible versions are unavailable, revert the sbt version back to 1.12.12.

Loading