Skip to content

bloop v1.1.0
Compare
Choose a tag to compare
@bloopoid bloopoid released this 03 Dec 10:53
v1.1.0
3532723
This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
GPG key ID: 4AEE18F83AFDEB23
Expired
Learn about vigilant mode.

Install v1.1.0 🍬

If you're on Mac OS X, upgrade to the latest version with:

$ brew install scalacenter/bloop/bloop

Otherwise, run:

$ curl -L https://github.com/scalacenter/bloop/releases/download/v1.1.0/install.py | python

Read the complete installation instructions in our Installation page.

What is bloop

Bloop is a Scala build server and command-line tool to make the compile and test developer
workflows fast and productive in a build-tool-agnostic way. Learn more about Bloop and its origins
in this ScalaDays Berlin talk.

Highlights 📚

Build Server Protocol 2.0

The new version of the protocol, a joint effort of Olafur Páll Geirsson (Scala Center),
Justin Kaeser (JetBrains) and Jorge Vicente Cantero (Scala Center), simplifies client
integrations, improves task notifications and diagnostics reporting, adds a new BSP connection
protocol to discover BSP servers and polishes v1.0.0.

Despite the fact that there is not a stable BSP v2.0 release out yet, Bloop adds initial support
for BSP v2.0.0-M2, which is also implemented by IntelliJ 2018.3.504 and Metals 0.2.3. This means
you can use bloop v1.1.0 with both Metals and IntelliJ.

Full support for BSP 2.0 (for example, testing and running via the protocol) will soon be
available in future bloop versions.

New editor integration: Metals

Build import and compiler diagnostics in Metals are powered by bloop v1.1.0. This release adds a
lot of small usability and correctness fixes to make bloop a fitting server for Metals. Metals
supports several editors (such as vim and Visual Studio Code) and has best-in-class bloop
integration (for example, every time there is a change in an sbt build, Metals can ask you to
reload the build and run bloopInstall automatically). Try out Metals
here.

Experimental build pipelining

Build pipelining is a compilation performance technique to start the compilation of modules in
a build before their dependencies have finished compilation. An experimental implementation of
build pipelining has been pioneered and merged in bloop v1.1.0.

How to use build pipelining

Build pipelining is not yet ready for mainstream use (incremental compilation is not supported yet).

However, v1.1.0 adds experimental support to allow bloop clients check compilation speedups with
build pipelining. To benchmark build pipelining, bloop clean your project and add --pipeline
to your bloop compile invocation. Clean and repeat the process to warm up the compiler as many
times as the compilation numbers you have for raw compilation.

No incremental compilation

At the moment, build pipelining doesn't work with incremental compilation so it's not a great fit
for day-to-day use. Improvements on this area are staged for the future.

Performance results

Bloop compiles its community build successfully under build pipelining. The community build
includes the following projects: apache/spark, lihaoyi/utest, scala/scala, ornicar/lichess,
twitter/scalding, akka akka, twitter/finagle, sbt/sbt, twitter/algebird,
twitter/scalatra, guardian/frontend, netflix/atlas and guardian/grid.

The results of build pipelining are positive but are not yet fully confirmed. Compilations of
projects such as apache/spark, twitter/finagle and ornicar/lila give significant speedups.
There are reasons to think future versions of bloop and Scala (2.12.8 and 2.13.0) will improve the
performance of build pipelining. You can see that current results range from 0% to 32% compilation
speedup.

Java and Scala order

When build pipelining is run on projects that define Java and Scala sources, build pipelining
becomes more challenging. The current bloop implementation handles this transparently to the user
and defaults on a reasonable policy that works in our current community build. The downside is
that users don't have a lot of flexibility in using build pipelining and making sure it works in
their project without source changes.

In next versions, this limitation will go away and there will be an explicit mechanism for users
to control the order in which Java and Scala are compiled and its intra-build dependencies.

Test Scala.js projects

Thanks to #706, contributed by @tindzk and
@jvican, bloop v1.1.0 can now test Scala.js 0.6.x and 1.x projects and link projects
using CommonJS modules. After this change, the only missing bit is to test Scala Native projects.

A new Gradle integration

Thanks to Daniel Silva and Daniel Vigozovsky, bloop features a Gradle installation. To learn how to use bloop with Gradle, head to the installation instructions.

Improvements since 1.0.0

  1. Watch changes in single files
  2. Remove default dependency between test sources in sbt
  3. New additions to our community build
  4. Add better feedback if configuration directory is missing
  5. Make compile watch clear screen before first run
  6. Improve benchmarks infrastructure with
    async-profiler
  7. Enable benchmarks for more projects
  8. Speed up build loading and minimize its IO
  9. Clean all projects by default
  10. Print error if download fails in install.py
  11. Add support for local homebrew formulas
  12. Apply system properties to all test frameworks
  13. Don't fail bloopInstall on builds of one single sbt plugin
  14. Add --debug parameter to control verbosity of logs
  15. Support proxy in coursier integration
  16. Allow to run externally-defined main classes
  17. Terminate processes gracefully
  18. Handle build load errors gracefully in the server
  19. Add resources to the configuration file
  20. Create target path of -h ScalaTest option
  21. Add fish tab completion capabilities
  22. Use another hash code for projects
  23. Add tests for running dependent main
  24. Prove transitive resources are used in aggregated projects
  25. Set cwd to project's base directory
  26. Set jvm proxy from client environment variables
  27. Fix test resource behavior for source-based projects
  28. Improve compilation reporting to users
  29. Propagate main class in sbt plugin

Improvements on the Build Server Protocol implementation

  1. Use bsp 1.0.0 and implement its new methods
  2. Allow bloop reflective invocation with cancellation
  3. Don't error on trace message
  4. Upgrade to latest bsp version
  5. Upgrade to bsp 1.0.1 to use status code
  6. Reload and save state during BSP actions
  7. Publish diagnostics for syntax errors and improve tests
  8. Return correct platform for BSP Scala targets
  9. Re-publish diagnostics for warnings
  10. Migrate to bsp 2.0.0 partially
  11. Re-publish all warnings on BSP server startup

Contributors 👥

According to git shortlog -sn --no-merges v1.0.0..v1.1.0, 17 people contributed to this
v1.1.0 release: Jorge Vicente Cantero, Martin Duhem, Tim Nieradzik, Daniel Silva, Paweł
Bartkiewicz, Daniel Vigovszky, Josep Prat, Etienne Couritas, Jens Grassel, Martin Mauch, Qi Wang,
Ashwin Raja, David Francoeur, Kevin Rauscher, Octavian Genes, Reto Habluetzel, fanconepl, ioleo.

The core team is grateful to all the contributors that have submitted PRs and helped
improved the documentation of Bloop. Thanks a lot!

Assets 5
Loading