Request for feedback: sbt 1.2.0 roadmap


#1

Hi everyone. On behalf of Tooling Team at Lightbend, I would like to share the plans for the upcoming 1.2.0 release that we are planning for this spring. Please see the announcement blog post: sbt 1.2.0 roadmap on Lightbend’s Tech Hub.

With the release of sbt 1.1.0 out, we want to solicit feedback from you, the sbt community. If you have ideas for any of the topic discussed in this post or otherwise, please let us know by commenting in this thread.

Thanks,
Dale Wijnand / Tooling Team / Lightbend, Inc.


#2

q1: Coursier!

a1: There’s an ongoing effort to integrate Coursier as an implementation of sbt’s library management API. Please check out https://github.com/sbt/librarymanagement/pull/190


#3

I think many sbt plugins are using sbt-sonatype https://github.com/xerial/sbt-sonatype for publishing to Maven central. As the author of sbt-sonatype, I just need to know when I can start using sbt 1.2.0. Please ping me if it becomes ready to use.


#4

As an author of sbt-sonatype, I just need to know when I can start using sbt 1.2.0. Please ping me if it becomes ready to use.

To clarify, sbt 1.x series is on Semantic Versioning, so all sbt 1.x plugins will continue to work in 1.2, just like in 1.1.0.


#5

(in addition to Coursier integration :wink: )

it would be great if /usr/bin/sbt was now written (in a presumably non-JVM language) as a LSP client in order to provide the benefits of long-running SBT instances to people who’d rather stick to bash’s command history & completion as The Loop.

(it’s already kind of not a straight jar already, but you get the idea: transform the sbt experience into “always use LSP” without changing anything on the existing user interfaces, just faster throughout)


#6

Please add to the roadmap support of JDK 10 and handy multi-platform builds for Scala projects with multiple submodules partially-cross-published against JVM, JS and Native.


#7

it would be great if /usr/bin/sbt was now written (in a presumably non-JVM language) as a LSP client in order to provide the benefits of long-running SBT instances to people who’d rather stick to bash’s command history & completion as The Loop.

The idea of splitting has long existed (for example Activator UI), but full replacement of sbt frontend requires a lot of work. So I would suggest aiming for some smaller progress, like supporting compile and test. I’ve created https://github.com/sbt/sbt/issues/3915 that aggregates thin client related issues.


#8

“clean compile test assembly run” is pretty much everything I’d need
from a thinsbt front-end, and would be of tremendous help. Especially if
"thinsbt" is written in a way that punts to the classic (heavy)
front-end for everything it doesn’t immediately understand how to push
through LSP.


#9

Not sure how easy it is, but can we make sbt load time faster? Used to be significantly faster in 0.13.x. Thank you!


#10

Java 9

Specifically, we need intuitive and convenient syntax for working with modules.


#11

I suggest fixing all the bugs that the support for source dependencies has.


#12

Please add to the roadmap support of JDK 10 and handy multi-platform builds for Scala projects with multiple submodules partially-cross-published against JVM, JS and Native.

We wanted to make the roadmap focused, so we didn’t specifically include JDK n support for 1.2, but we’ve been thinking about JDK 9, 10, and more importantly 11 LTS.


#13

Focussed is fine, and LTS support is important… But right now there’s a very real and pressing need to be able to simply compile projects without errors and without tedious management of multiple JDK versions when the user has JDK9 installed.

This is doubly true given the EOL status of JDK 8

So although targeting a specific numbered JDK isn’t relevant, targeting specific features of those JDKs that present challenges is vital. In this case it’s the ability to import modules (notably the JAXB/bind/xml stuff), which currently makes JDK 9 off-limits to many Scala projects. There are ways to make it work right now, but the right incantations to do so are currently something of a poorly documented black art… There has to be a better way!

Note that this isn’t a request for full buy-in to be able to import/export and otherwise interact with the full feature set of project Jigsaw. All that’s needed right now is a simple way to specify the import of those modules that used to be in the standard library under JDK 8 and earlier.


#14

Focussed is fine, and LTS support is important… But right now there’s a very real and pressing need to be able to simply compile projects without errors and without tedious management of multiple JDK versions when the user has JDK9 installed.

For the record, Scala team has been working on JDK 9 support (for example https://github.com/sbt/sbt/pull/2951 was sent Feb 2017, Scala 2.12.4, 2.11.12, 2.10.7, and sbt 0.13.17 were released to add JDK 9 compatibility, etc). And we want to make sure people can build things in JDK 9.

This is doubly true given the EOL status of JDK 8

JDK 9 is going to be EOL next month (March, 2018). JDK 8 is planned for EOL September, 2018.

All that’s needed right now is a simple way to specify the import of those modules that used to be in the standard library under JDK 8 and earlier.

Specifically for Java EE modules like JAXB, isn’t the proper migration just adding appropriate libraryDepedendencies according to Migrating to JDK 9?

If there is a specific thing that’s blocking you from using JDK 9, could you open a GitHub issue for it or comment in https://github.com/scala/scala-dev/issues/139 please?


#15

Yes, the magic incantation for most cases is to add libraries. Unfortunately a lot of websites out there seem to be advocating --add-modules. I think it would help a great deal here if we could handle JDK migrations against an otherwise unchanged codebase.

Being able to trap these failures and offer error messages recommending what needs adding would be one option, as would some helper syntax to import those libraries that correspond to specific modules that were previously in core.


#16

I suggest fixing all the bugs that the support for source dependencies has.

I created https://github.com/sbt/sbt/issues/3918 that aggregates the current issues with source dependencies. Are there more?

It would be good to at least get the feature documented.


#17

It would be great if it was possible to add sbt options and plugins to source dependencies. Currently localProject / scalaVersion := "2.12.4" works, but projectRef / scalaVersion := "2.12.4" doesn’t.


#18

I’ve documented in that ticket all the issues I’ve found when doing source dependencies in sbt.

Note that fixing those issues is not easy. But I believe that source dependencies (even in different git repos) are proving more than useful, popular build tools like Pants and Bazel are a living proof. If sbt had complete support for source dependencies, it would hit a sweet spot between Maven and Gradle (traditional build tools that don’t have source deps support), and Bazel and Pants (which have excellent support for source deps, but whose model is somewhat limited for what normal JVM developers are used to).


#19

Performance. Upgrading from 0.13.15 to 1.0.x or 1.1.0 results in compilation speed taking 30% longer. IMO this should be considered of the highest priority.


#20

I see the discussions here about source dependencies. This would be great! But meanwhile, regular binary dependencies cause builds to fail every day. See recent thread:


What I suggest, is try to implement an old issue that lies around for quite some time now:

This isn’t “sexy” as source dependencies, but practically solve a real problem.