Skip to content

Cross build for sbt 1.x and 2.x - #245

Open
eed3si9n wants to merge 2 commits into
scala-garden:mainfrom
eed3si9n:wip/sbt2
Open

eed3si9n wants to merge 2 commits into
scala-garden:mainfrom
eed3si9n:wip/sbt2

Conversation

@eed3si9n

Copy link
Copy Markdown
Contributor

This cross builds the plugin portion to sbt 1.x and 2.x, and migrates the driver to Scala 3.

I used Claude to migrate the library usages to something that's available on Scala 3:

Before After
Dispatch HTTP Gigahorse Apache Client
Jacks Circe
Akka Apache Pekko

Due to the limitation on sbt's launcher, sbt 2.x I don't think can fully override the Scala toolchain yet. Integration test seems to pass on both sbt 1.x and 2.x.

Comment on lines +24 to +30
// "standard" (rather than an explicit "3.8.4") avoids a genuine dbuild gap: the
// extraction-side Scala-version override (DependencyAnalysis.fixExtractionScalaVersion2)
// only rewrites Keys.scalaVersion and lets sbt's own legacy compiler-fetch fallback run,
// which isn't Scala-3-aware and looks for the old "scala-compiler" module instead of
// "scala3-compiler_3". sbt 2.0.7 already defaults to Scala 3.8.4 on its own, so no
// override is needed here anyway.
injectIntoMetaMetaBuild(projectName = "InjectionTest2x", sbtVersion = "2.0.7", extractionVersion = "standard")

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

This might require some follow-up.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

“genuine” is one of my pet LLM tells :-)

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

This might require some follow-up

Do I understand correctly that this is only about being able to override the Scala version used to compile the build, as opposed to the Scala version for project code? Because in the Scala 2 community build we only care about the level 0 Scala version.

Do you expect to care about this when using dbuild to test sbt 2...?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Do I understand correctly that this is only about being able to override the Scala version used to compile the build, as opposed to the Scala version for project code?

I'm not totally sure, but my guess is that it's currently not able to switch out to a freshly baked Scala 3 compiler?

Do you expect to care about this when using dbuild to test sbt 2...?

Nope.

Comment thread build.sbt
def MyVersion: String = "0.9.20"

ThisBuild / scalaVersion := scala212
ThisBuild / scalaVersion := scala3

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Since I'm using Scala 3.8.4, this would also bump the minimum JDK version to JDK 17. This can easily be flipped since the driver code current cross compiles.

@SethTisue

Copy link
Copy Markdown
Contributor

About JDK 17 as a new baseline: it might be fine for the Scala 2 community build to stay on old dbuild on JDK 8 (we already dropped 11), or to drop JDK 8 entirely.

I've just written that possibility up at scala/community-build#1747

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

2 participants