Add sbt 2.0 crossbuilds

[BillyAutrey]

Expected behaviour

If a user crossbuilds or sets sbt to 2.x in build.properties, then they should be able to pull a version of sbt-native-packager successfully.

Actual behaviour

You get 404s trying to pull sbt 2.0.0-M2 artifacts.

Information

• Requires compatibility with 1.10.2 of sbt
• Requires migrating away from slash syntax
• Requires Scala 3 support

[BillyAutrey]

So far, looks like @jtjeferreira is working on at least slash syntax for this: #1636

[jtjeferreira]

So far, looks like @jtjeferreira is working on at least slash syntax for this: #1636

Yes, I am working on this

[agboom]

@jtjeferreira are you also working on the cross build for 2.x? If not, I'm also willing to pick it up :)

[jtjeferreira]

@jtjeferreira are you also working on the cross build for 2.x? If not, I'm also willing to pick it up :)

slowly, but I am working on it. The File to HashedVirtualFileRef migration cross compilation is not easy though...

[agboom]

Yes, I ran into that as well. I can push my work so far if it helps

[agboom]

Here's what I got so far: agboom@0ae7c53#diff-5634c415cd8c8504fdb973a3ed092300b43c4b8fc1e184f7249eb29a55511f91R6

I left off at making Scala 3 compile and extending the cross source (Compat, MappingsHelper, SettingsHelper) so that it works with the new HashedVirtualFileRef while taking the difference with sbt 1.x into account. I think I got the artifactStr and moduleIDStr settings right, but I haven't arrived at testing (yet). Hope it's of any help.

[BillyAutrey]

Have you seen this?
https://www.scala-sbt.org/2.x/docs/en/changes/migrating-from-sbt-1.x.html#the-plugincompat-technique

Obviously not exhaustive, I'm running into a similar issue that needs more implicit conversions than listed in this example. But it's a little more future proof - we'll be moving to M3 before long, so putting this in the scala-3 compatibility directory will be more beneficial.

[agboom]

@BillyAutrey I missed that, thanks for the pointer! It looks somewhat like my solution, but a lot cleaner. For native-packager I think there also needs to be a shim for the artifact and module setting interaction, because that has changed too (e.g. agboom@0ae7c53#diff-f735fb04cdf31ac953f28d0ae8515eb78b364cb0fd408bd914f8a1ba8e8c40e8R154)

[jtjeferreira]

Have you seen this?
scala-sbt.org/2.x/docs/en/changes/migrating-from-sbt-1.x.html#the-plugincompat-technique

No I didn't, but I saw something similar in sbt-pgp

I didn't made much progress, but I added some more commits to #1636. Would be good to merge that first.

[eed3si9n]

Not working yet, but I have a draft PR - #1647

[agboom]

@eed3si9n Nice! I had just started on my fork again by rebasing it onto mainline, but it looks like yours is further along and has some nice cleanups as well 👍

I think mimaPreviousArtifacts needs a conditional on the sbtBinaryVersion to make CI continue: https://github.com/sbt/sbt-native-packager/pull/1647/files#diff-5634c415cd8c8504fdb973a3ed092300b43c4b8fc1e184f7249eb29a55511f91R82-R91

Probably scalacOptions needs -Xsource:3 to make the import sbt.{*, given} syntax compile for 2.12? At least that's what I ran into.

[eed3si9n]

Here's an offshoot PR to migrate the unicode arrow - #1648

[muuki88]

I'm totally fine to release a 2.x version of sbt-native-packager if necessary to make this work