support sbt 1.x

[SethTisue]

practice what we preach

[godenji]

Can't publishLocal scala-xml with sbt 1.0 support due to this issue

Actually, nevermind, can just bump scala-xml's build.properties to 0.13.16 and ^publishLocal. Though it is a shame to have to download the entire sbt 0.13/scala 2.10 universe to build the project.

[SethTisue]

on hold until there is an sbt 1.x release that is Scala 2.13 friendly (the ticket on that is sbt/sbt#3427)

[SethTisue]

sbt 1.1.0 is Scala 2.13-friendly, so this can move forward now.

[lrytz]

cool! i'm still planning to push my work on supporting js/native through, which will (most likely) include an sbt 1 upgrade. current state summarized in scala/scala-parser-combinators#132 (comment).

[Sciss]

ping!

[SethTisue]

using sbt 1 requires building on Java 8. this is problematic because we still build the modules for Scala 2.11 on Java 6.

I suggest we drop Scala 2.11 support in all the modules, or at least, in any module wanting to upgrade to sbt 1 on its current development branch. (modules wanting to continue to release new versions for Scala 2.11 could do so from an older branch using sbt 0.13.)

then we can standardize on Java 8 and everything becomes simpler.

what do you think @lrytz?

[Sciss]

I wouldn't drop 2.11 support. Is there a problem compiling modules for 2.11 running on a JDK 8? you can still have a java target of 1.6 if it includes Java sources.

[SethTisue]

Is there a problem compiling modules for 2.11 running on a JDK 8?

the danger is that you accidentally use Java 7 or 8 APIs, and then the resulting module doesn't work on Java 6 or 7.

so, another possibility in this space is to keep 2.11 support but drop Java 6 and 7 support and build everything on 8.

[Sciss]

Right - so I will opt for sticking to sbt 0.13 for the Swing module then.

[dwijnand]

another possibility in this space is to keep 2.11 support but drop Java 6 and 7 support and build everything on 8.

You could do that in a new version series of this plugin, so modules could independently give up on Java 6/7 and upgrade to sbt 1.

[SethTisue]

You could do that in a new version series of this plugin

Yeah. I like it. We could start with scala-parallel-collections, which is already Scala 2.12+/Java8+ only anyway. And with scala-java8-compat, which supports 2.11 but (obviously) requires Java 8+.

I've also submitted a PR to scala-async to drop 2.11 support there, not sure if Jason will merge that one or not.

[SethTisue]

(Lukas is on vacation this week, so we'll have to wait for this thoughts.)

[lrytz]

I have nothing to add :-) agree with the agreements.

[SethTisue]

Right - so I will opt for sticking to sbt 0.13 for the Swing module then.

I've made a new ticket to discuss that separately: scala/scala-swing#79

[som-snytt]

I tried this today, in fact on the swing module.

[SethTisue]

I deleted the master branch and created 1.x and 2.x branches (pointing to the same commit, to start). 1.x can continue as before, and I'll working on switching to sbt 1 on the 2.x branch

note that the outcome of the scala-swing discussion was that it's fine to switch their own 2.0.x branch to sbt 1

[SethTisue]

WIP at #50. (I am secretly hoping to nerd-snipe @dwijnand and/or @eed3si9n into helping with the needed code changes — shhhhhhhhhh!)

[SethTisue]

keeping the ticket open until we've actually published a release and used it on at least one actual module

[SethTisue]

plugin 2.0.0 is published

I'm trying it out at scala/scala-partest#116 and https://github.com/scala/scala-partest/releases/tag/v1.1.9 and scala/scala#7774

[SethTisue]

well I'm running some partests in scala/scala locally and they're passing, so I think we can declare victory here