sbt 1.0 roadmap

[eugene yokota]

Hi folks,

I wrote up sbt 1.0 roadmap - http://eed3si9n.com/sbt-1-roadmap

A midterm mission statement of sort.

-eugene

[Alexey Alekhin]

Thanks for writing this post.

About sbt-archetype: I think that the "new" command of Activator is very limited (if I understand it right), because it doesn't have substitutable placeholders. It would be nice to have functionality of giter8 in sbt: it substitutes placeholders not only inside of the files, but also in filenames. And allows customisable formatting for them.

 

[Aleh Aleshka]

Thanks Eugene.
This all sounds very promising.
I'd like to additionally suggest inclusion of several plugins which are useful in every project. atm i'd consider https://github.com/tototoshi/sbt-build-files-watcher and sbt-revolver to be this kind of plugins

Aleh

[Simon Ochsenreither]

Would be nice to ship the IDE project file plugins by default. I think the amount of people not using any kind of IDE/editor support for Scala is quite limited.

[Naftoli Gugenheim]

Plugins plural? IntelliJ doesn't need an sbt plugin. Eclipse sort of makes sense because they're both lightbend. What about ensime? Also, what about lots of other plugins that are super-useful for basic things, like viewing dependency graphs, or like sbt-native-packager (it's an autoplugin, so just having it doesn't have much impact).

Also, what does it mean to ship it? Just that sbt should create some files in ~/.sbt/0.13/plugins? What if you upgrade sbt but a file with the same name exists?

On Sun, Mar 13, 2016 at 5:35 PM Simon Ochsenreither <simon.och...@gmail.com> wrote:

Would be nice to ship the IDE project file plugins by default. I think the amount of people not using any kind of IDE/editor support for Scala is quite limited.

--
You received this message because you are subscribed to the Google Groups "sbt-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sbt-dev+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sbt-dev/2317b1db-ef17-452d-97bb-67da71cc8463%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Joe Kutner]

While there may be a limited number of people who do not use an IDE, there are probably more machines running sbt than people. CI servers, Docker containers, and platforms like Heroku all run sbt without an IDE. Adding a set of IDE plugins by default would add bloat (and most Docker images try to prune down to just the essentials anyways).

[Naftoli Gugenheim]

I think it could be an alternative download option.

How many ways do most people install sbt? The most common I'm aware of are:
1) Browse to scala-sbt.org, download the package installer for your platform
2) On Mac, brew install sbt
3) Get the launcher jar and run it with a simple script (probably only in CI or docker containers)

To view this discussion on the web visit https://groups.google.com/d/msgid/sbt-dev/7c8f4ef4-f010-42f4-9dd2-fc759ffbf82b%40googlegroups.com.

[Jacek Laskowski]

Hi,

I fully support inclusion of sbt-revolver.

I'd also throw in sbt-assembly which is the default way to assemble applications for Apache Spark. I hardly believe there's a better way to the combo: sbt + sbt-assembly and consider sbt-assembly an integral part of Spark/Scala stack (I even created https://github.com/jaceklaskowski/spark-workshop so I know Internet is not an issue -- which still is...even in Canada!)

Best,

Jacek

[Aleh Aleshka]

Now, sbt-assembly and sbt-native-packager are both fine ways to package the app, and i'd say the latter is preferable in most cases. That means we'd probably need to include both, which is a bit too much imo.

[Sam Halliday]

I'm against including plugins by default. If you want some plugins by default at your sites, it's easily scripted and in any case is automatic.

Let's keep sbt core small to speed up first time installs and to keep the footprint low for corporate adoption.

Where will the discussion end, should all versions of Scala compiler be distributed too "just in case".

[Simon Ochsenreither]

Where will the discussion end, should all versions of Scala compiler be distributed too "just in case".

I'm writing a native wrapper¹ around SBT to download, manage and install OpenJDKs ... maybe some kind of "fat"-jar is worth it? I think it will be much faster than the current situation of downloading dozens of tiny jar files.

¹ In Rust ... painful and amazing at the same time. :-)

[Aleh Aleshka]

There are some plugins which provide behavior that _all_ users want, eg. lots of newbies waste considerable amount of time because functionality of sbt-build-files-watcher and sbt-revolver is not available by default.