v1.3.0

bloop v1.3.0

Bloop is a build server and CLI tool for the Scala programming language
developed by the Scala Center.

Bloop v1.3.0 is the biggest release of this project to this date.

With over 520 commits since the v1.2.5 release, ~26000 additions and ~9500
deletions, it aggregates together fundamental changes in the compilation
pipeline, novel build server features, user-facing improvements and bug fixes
together.

Upgrade guide 📥

These are only the upgrade steps. If you don't have bloop installed, you must read
the [installation instructions][] instead.

If you're on macOS, upgrade to the latest version with:

$ brew upgrade scalacenter/bloop/bloop
$ brew services restart bloop # Note a restart is required in case a server still runs!

If you're on Windows using scoop, upgrade to the latest version with:

$ scoop upgrade bloop
$ bloop ng-stop
$ bloop server # in a long-running terminal session

🆕 If you're on Arch Linux, upgrade to the latest version with:

$ rm -rf ~/.bloop
$ yaourt -S bloop
$ systemctl --user start bloop

Otherwise, use the generic installation method:

$ curl -L https://github.com/scalacenter/bloop/releases/download/v1.3.0/install.py | python
$ bloop ng-stop
$ systemctl --user start bloop # or similar way to run server in a long-running session

Read the complete installation instructions in our [Installation page][installation instructions].

New compilation engine with client guarantees 💪 👪

v1.3.0 features a redesigned compilation engine built to solve tooling
challenges already present in our current developer workflow but brought to
the foreground by the formalized use of a client-server architecture. This
compilation engine sports a more efficient way of doing IO work (with no
compromises in correctness) and provides a new contract to build clients.

Bloop v1.3.0 and onwards guarantees clients that their actions will have
the smallest usage footprint possible and will not conflict with those of
other concurrent clients being served by the same server in the same build.

For example, if [Metals] is compiling your project via Bloop and you spawn a
bloop CLI command such as bloop test foo --watch at the same time, Bloop
guarantees that:

1. The server heavily caches compilations for the same inputs (aka compile deduplication)

   If inputs haven't changed between the requests, only the first client
   request will trigger a compilation. The compilation of the second client
   will be deduplicated based on the compilation side effects recorded by the
   build server, so only one compilation will happen.

2. Different compilation requests in the same build can run concurrently (aka
   compile isolation)

   If inputs have changed between requests, Bloop will compile the changed
   projects concurrently, avoiding shared state and conflicts with ongoing
   compilations.

3. The outputs produced by both requests are independent in the file system.

   The compilation products will be stored in independent target
   directories only owned by the client. This independence is essential to
   allow clients to independently run any build action without altering task
   executions. Think avoiding crashing JVMs because other processes are
   writing contents to open class file pointers!

This is the first step towards modelling these build actions as pure
functions despite their pervasive side effects. Bloop manages any internal
state as best as possible to provide the best developer experience to end
users. There will be more work in this area in the future!

Related pull requests

1. Isolate and deduplicate compilation and Zipkin tracing support by [jvican]
2. Pre-populate client classes dir if empty by [jvican]
3. Deduplicate compilation if project inputs change by [jvican]
4. Invalidate symbols with forked and local javac by [jvican]
5. Don't create and delete empty classes dirs by [jvican]
6. Cancel deduplication if ongoing compilation looks dead by [jvican]
7. Use generic classes dir for the pipelined traversal by [jvican]
8. Log to the user a deduplication is happening by [jvican]
9. Revalidate class files compiled by dependent projects by [jvican]
10. Fix not found type errors during incremental compilation by [jvican]
11. Add CLI lock timeout and be more flexible when locking CLI clients
12. Fix remaining issues around handling of compile products by [jvican]
13. Catch exceptions when computing the bundle by [jvican]

New Zipkin tracing support 📡

Bloop v1.3.0 traces any compilation request to Zipkin if a Zipkin server is
running in the background. Here's a screenshots showing collected compilation
traces for the akka/akka project.

And another screenshot showing the top part of a detailed compilation trace.

The zipkin integration is explained in the performance guide below.

In-depth compiler performance guide 🚀

The compiler performance
guide is a new
addition to our documentation that explains users how to:

1. Get familiar with the performance characteristics of project builds
2. Compare the performance of Bloop with that of other tools compiling Scala code
3. Modify a complicated build to optimize build times

The guide is rich in details and written to provide pointers to those users
wanting to speed up their workflow with Bloop and optimize their current
build times further.

It is open for any community addition, so if you'd like to add something,
help us improve it!

Faster build pipelining 🏇

Build pipelining is a compilation performance technique to start the
compilation of modules in a build before their dependencies have finished
compilation.

Build pipelining was merged back in December, 2018 and made available in
bloop v1.2.1, making bloop the first Scala developer tool to implement this
technique and support it under an experimental flag.

Bloop v1.3.0 changes its internal implementation to make it faster. We're
very excited about what this entails for any Scala build in the wild. The
bloop project will publish benchmarks and a concise guide in a follow-up
post, keep tuned! 😄

Use Ammonite by default in bloop console 🎮

Contributed by @[torkelrogstad].

Ammonite is a modernized Scala REPL with syntax highlighting, multi-line
editing, the ability to load maven artifacts directly in the REPL, and many
other quality-of-life improvements missing in the default Scala REPL.

Bloop v1.3.0 defaults on Ammonite every time you run bloop console on a
project. Unlike running amm in your terminal, the Ammonite integration will
automatically start an Ammonite REPL using the classpath of a project in your
build. That allows you to use all the code defined in that classpath and
experiment with its behavior.

Interested in the implementation details? Have a look at
Add support for Ammonite REPL by default.

Better Metals and BSP integration 🤘 💯

BSP support in bloop v1.3.0 is vastly superior to that in v1.2.5. The new
release implements a few non-implemented endpoints, fixes several
non-reported issues in diagnostics and improves connection support and
cancellation capabilities.

The Metals integration is superior to that in v1.2.5 thanks to this
non-exhaustive list of PRs:

1. Guarantee cancellation upon sudden BSP client dropouts by [jvican]
2. Upgrade to BSP 2.0.0-M4 by [tgodzik]
3. Implement BSP buildTarget/scalaMainClasses by [marek1840]
4. Implement BSP buildTarget/scalaTestClasses by [marek1840]
5. Send out server BSP responses/notifications in order by [jvican]
6. A few unlisted PRs that casually fix issues in BSP semantics

Add support for Scala 2.13 ▶️

Bloop v1.3.0 finally adds support for Scala
2.13.x.

Add support for JDK 9 and 11 ⏩

Contributed by @[er1c], bloop v1.3.0 supports JDK 9 and JDK 11. If you run
bloop with these Java runtimes, it is recommended to enable the full parallel
GC with -XX:+UseParallelGC as compilation is faster.

For this reason, Java 8 still remains the recommended runtime for the time
being and our installers might install it by default. In the future, we might
consider upgrading to a newer Java runtime.

1. Compile on Java9+ by [er1c]
2. Add Java9+ reverse-compatible changes by [er1c]

New Arch ...

v1.3.0-RC1

bloop v1.3.0

Bloop is a build server and CLI tool for the Scala programming language developed by the Scala Center.

Bloop v1.3.0 is the biggest release of this project to this date.

With over 520 commits since the v1.2.5 release, ~26000 additions and ~9500
deletions, it aggregates together fundamental changes in the compilation
pipeline, novel build server features, user-facing improvements and bug fixes
together.

Upgrade guide 📥

These are only the upgrade steps. If you don't have bloop installed, you must read
the [installation instructions][] instead.

If you're on macOS, upgrade to the latest version with:

$ brew upgrade scalacenter/bloop/bloop
$ brew services restart bloop

If you're on Windows using scoop, upgrade to the latest version with:

$ scoop upgrade bloop
$ bloop ng-stop
$ // Start the server as you usually do (via systemd, manually, desktop services)

🆕 If you're on Arch Linux, upgrade to the latest version with:

$ rm -rf ~/.bloop
$ yaourt -S bloop
$ systemctl --user start bloop

Otherwise, use the generic installation method:

$ curl -L https://github.com/scalacenter/bloop/releases/download/v1.2.5/install.py | python
$ bloop ng-stop
$ // Start the server as you usually do (via systemd, manually, desktop services)

Read the complete installation instructions in our [Installation page][installation instructions].

New compilation engine with client guarantees 💪 👪

v1.3.0 features a redesigned compilation engine built to solve tooling
challenges already present in our current developer workflow but brought to
the foreground by the formalized use of a client-server architecture. This
compilation engine sports a more efficient way of doing IO work (with no
compromises in correctness) and provides a new contract to build clients.

Bloop v1.3.0 and onwards guarantees clients that their actions will have
the smallest usage footprint possible and will not conflict with those of
other concurrent clients being served by the same server in the same build.

For example, if Metals is compiling
your project via Bloop and you spawn a bloop CLI command such as bloop test foo --watch at the same time, Bloop guarantees that:

1. The server heavily caches compilations for the same inputs (aka compile deduplication)

   If inputs haven't changed between the requests, only the first client
   request will trigger a compilation. The compilation of the second client
   will be deduplicated based on the compilation side effects recorded by the
   build server, so only one compilation will happen.

2. Different compilation requests in the same build can run concurrently (aka
   compile isolation)

   If inputs have changed between requests, Bloop will compile the changed
   projects concurrently, avoiding shared state and conflicts with ongoing
   compilations.

3. The outputs produced by both requests are independent in the file system.

   The compilation products will be stored in independent target
   directories only owned by the client. This independence is essential to
   allow clients to independently run any build action without altering task
   executions. Think avoiding crashing JVMs because other processes are
   writing contents to open class file pointers!

This is the first step towards modelling these build actions as pure
functions despite their pervasive side effects. Bloop manages any internal
state as best as possible to provide the best developer experience to end
users. There will be more work in this area in the future!

Related pull requests

1. Isolate and deduplicate compilation and Zipkin tracing support by [jvican]
2. Pre-populate client classes dir if empty by [jvican]
3. Deduplicate compilation if project inputs change by [jvican]
4. Invalidate symbols with forked and local javac by [jvican]
5. Don't create and delete empty classes dirs by [jvican]
6. Cancel deduplication if ongoing compilation looks dead by [jvican]
7. Use generic classes dir for the pipelined traversal by [jvican]
8. Log to the user a deduplication is happening by [jvican]
9. Revalidate class files compiled by dependent projects by [jvican]
10. Fix not found type errors during incremental compilation by [jvican]
11. Add CLI lock timeout and be more flexible when locking CLI clients
12. Fix remaining issues around handling of compile products by [jvican]
13. Catch exceptions when computing the bundle by [jvican]

New Zipkin tracing support 📡

Bloop v1.3.0 traces any compilation request to Zipkin if a Zipkin server is
running in the background. Here's a screenshots showing collected compilation
traces for the akka/akka project.

And another screenshot showing the top part of a detailed compilation trace.

The zipkin integration is explained in the performance guide below.

In-depth compiler performance guide 🚀

The compiler performance
guide is a new
addition to our documentation that explains users how to:

1. Get familiar with the performance characteristics of project builds
2. Compare the performance of Bloop with that of other tools compiling Scala code
3. Modify a complicated build to optimize build times

The guide is rich in details and written to provide pointers to those users
wanting to speed up their workflow with Bloop and optimize their current
build times further.

It is open for any community addition, so if you'd like to add something,
help us improve it!

Faster build pipelining 🏇

Build pipelining is a compilation performance technique to start the
compilation of modules in a build before their dependencies have finished
compilation.

Build pipelining was merged back in December, 2018 and made available in
bloop v1.2.1, making bloop the first Scala developer tool to implement this
technique and support it under an experimental flag.

Bloop v1.3.0 changes its internal implementation to make it faster. We're
very excited about what this entails for any Scala build in the wild. The
bloop project will publish benchmarks and a concise guide in a follow-up
post, keep tuned! 😄

Use Ammonite by default in bloop console 🎮

Contributed by @[torkelrogstad].

Ammonite is a modernized Scala REPL with syntax highlighting, multi-line
editing, the ability to load maven artifacts directly in the REPL, and many
other quality-of-life improvements missing in the default Scala REPL.

Bloop v1.3.0 defaults on Ammonite every time you run bloop console on a
project. Unlike running amm in your terminal, the Ammonite integration will
automatically start an Ammonite REPL using the classpath of a project in your
build. That allows you to use all the code defined in that classpath and
experiment with its behavior.

Interested in the implementation details? Have a look at Add support for Ammonite REPL by default.

Better Metals and BSP integration 🤘 💯

BSP support in bloop v1.3.0 is vastly superior to that in v1.2.5. The new release implements a few non-implemented endpoints, fixes several non-reported issues in diagnostics and improves connection support and cancellation capabilities.

The Metals integration is superior to that in v1.2.5 thanks to this
non-exhaustive list of PRs:

1. Guarantee cancellation upon sudden BSP client dropouts by [jvican]
2. Upgrade to BSP 2.0.0-M4 by [tgodzik]
3. Implement BSP buildTarget/scalaMainClasses by [marek1840]
4. Implement BSP buildTarget/scalaTestClasses by [marek1840]
5. Send out server BSP responses/notifications in order by [jvican]
6. A few unlisted PRs that casually fix issues in BSP semantics

Add support for Scala 2.13 ▶️

Bloop v1.3.0 finally adds support for Scala
2.13.x.

Add support for JDK 9 and 11 ⏩

Contributed by @[er1c], bloop v1.3.0 supports JDK 9 and JDK 11. If you run
bloop with these Java runtimes, it is recommended to enable the full parallel
GC with -XX:+UseParallelGC as compilation is faster.

For this reason, Java 8 still remains the recommended runtime for the time
being and our installers might install it by default. In the future, we might
consider upgrading to a newer Java runtime.

1. Compile on Java9+ by [er1c]
2. Add Java9+ reverse-compatible changes by [er1c]

New Arch Linux installer 🏄

Co...

v1.2.5

bloop v1.2.5 🏄

Upgrade guide 🔌

This section describes the upgrade steps. If you don't have bloop installed, please read
the installation instructions instead.

If you're on macOS, upgrade to the latest version with:

$ brew upgrade scalacenter/bloop/bloop
$ brew services restart bloop

If you're on Windows using scoop, upgrade to the latest version with:

$ scoop upgrade bloop
$ bloop ng-stop
$ // Start the server as you usually do (via systemd, manually, desktop services)

Otherwise, run:

$ curl -L https://github.com/scalacenter/bloop/releases/download/v1.2.5/install.py | python
$ bloop ng-stop
$ // Start the server as you usually do (via systemd, manually, desktop services)

Read the complete installation instructions in our Installation page.

Highlights 📚

v1.2.5 is only a bugfix release.

Report diagnostics better via BSP

Fix clearing of missing diagnostics when previous incremental compiler cycles
have failed, see #804 for more
information.

Contributors 👥

According to git shortlog -sn --no-merges v1.2.4..v1.2.5, 1 people contributed to this v1.2.5
release: Jorge Vicente Cantero.

v1.2.4

bloop v1.2.4 🏄

Upgrade guide 🔌

This section describes the upgrade steps. If you don't have bloop installed, please read
the installation instructions instead.

If you're on macOS, upgrade to the latest version with:

$ brew upgrade scalacenter/bloop/bloop
$ brew services restart bloop

If you're on Windows using scoop, upgrade to the latest version with:

$ scoop upgrade bloop
$ bloop ng-stop
$ // Start the server as you usually do (via systemd, manually, desktop services)

Otherwise, run:

$ curl -L https://github.com/scalacenter/bloop/releases/download/v1.2.4/install.py | python
$ bloop ng-stop
$ // Start the server as you usually do (via systemd, manually, desktop services)

Read the complete installation instructions in our Installation page.

Highlights 📚

v1.2.4 is only a bugfix release.

Don't deduplicate diagnostics too aggressively

Fix an error where the deduplication logic of diagnostics to avoid duplicated scalac errors
relied on pointer instead of offset.

Contributors 👥

According to git shortlog -sn --no-merges v1.2.3..v1.2.4, 1 people contributed to this v1.2.4
release: Jorge Vicente Cantero.

v1.2.3

bloop v1.2.3 🏄

Upgrade guide 🔌

This section describes the upgrade steps. If you don't have bloop installed, please read
the installation instructions instead.

If you're on macOS, upgrade to the latest version with:

$ brew upgrade scalacenter/bloop/bloop
$ brew services restart bloop

If you're on Windows using scoop, upgrade to the latest version with:

$ scoop upgrade bloop
$ bloop ng-stop
$ // Start the server as you usually do (via systemd, manually, desktop services)

Otherwise, run:

$ curl -L https://github.com/scalacenter/bloop/releases/download/v1.2.3/install.py | python
$ bloop ng-stop
$ // Start the server as you usually do (via systemd, manually, desktop services)

Read the complete installation instructions in our Installation page.

Highlights 📚

v1.2.3 is only a bugfix release.

Don't fail installation when Python 3 is used and http_proxy is defined

See scalacenter/homebrew-bloop#4 for more details.

Disable failed process logs in launcher (#798)

This change clears up the logs of the launcher when processes are run and
they fail. See the linked pull request for more details.

Contributors 👥

According to git shortlog -sn --no-merges v1.2.2..v1.2.2, 2 people contributed to this v1.2.2
release: Jorge Vicente Cantero, marek1840.

v1.2.2

bloop v1.2.2 🏄

Upgrade guide 🔌

This section describes the upgrade steps. If you don't have bloop installed, please read
the installation instructions instead.

If you're on macOS, upgrade to the latest version with:

$ brew upgrade scalacenter/bloop/bloop
$ brew services restart bloop

If you're on Windows using scoop, upgrade to the latest version with:

$ scoop upgrade bloop
$ bloop ng-stop
$ // Start the server as you usually do (via systemd, manually, desktop services)

Otherwise, run:

$ curl -L https://github.com/scalacenter/bloop/releases/download/v1.2.2/install.py | python
$ bloop ng-stop
$ // Start the server as you usually do (via systemd, manually, desktop services)

Read the complete installation instructions in our Installation page.

Highlights 📚

v1.2.2 is a bugfix release.

Cache compiler plugins by default via a whitelist (#794)

Compiler plugins were found to have an important performance overhead in this scala/scala ticket.
As a result, a flag was added to cache the classloaders that loaded the compiler plugins on
every compilation run.

As that compilation flag is not well-known and most users don't even know they are using
macros/compiler plugins in their projects, it's been largely unused. This pull request tries to
change the current situation by enabling the flag for compiler plugins that have been checked to
be stateless. With this guarantee, we can enable the flag by default and provide out-of-the-box
the best compilation performance we know we can provide without any user intervention.

The compiler plugins added to the whitelist are: scala-js/scala-js, scala-native/scala-native,
wartremover/wartremover, scalameta/semanticdb, scalamacros/paradise, ghik/silencer,
sksamuel/scapegoat, scoverage/scalac-scoverage-plugin, lihaoyi/acyclic, non/kind-projector,
scalacenter/classpath-shrinker, scalacenter/scalac-profiling, softwaremill/scala-clippy,
oleg-py/better-monadic-for, tek/splain, scalaz/scalaz-deriving. They represent a big chunk of all
the compiler plugins used in the Scala community.

Bloop will not enable compiler plugin caching for Dotty and Scala 2.10, 2.11, 2.12.0, 2.12.1,
2.12.2, 2.12.3 and 2.12.4 versions. From 2.12.5 on, the flag is available in the compiler sources
and used.

Fore more information about the caching, check the pull request.

Improve diagnostics in the presence of -Yrangepos (#793)

Bloop v1.2.2 has now support for:

1. Pretty printing range positions in cli diagnostics of projects using -Yrangepos.
2. Report range positions in diagnostics for projects using -Yrangepos.
3. Deduplicates compiler diagnostics based on pointer position and severity.

Further improve BSP diagnostic reporting (#792)

Bloop v1.2.2 has improved diagnostics via BSP in the presence of no-op incremental compilations
and has changed the way progress notifications and task start/finish notifications are sent.

From this version on, progress notifications will be sent every 5% increments to avoid
overflooding the client with messages and defaulting on less but more user-friendly progress
notifications, that require almost no handling by the build client.

Likewise, task start and task finish notifications are sent now for every incremental compiler
run instead of for the whole batch compilation of a project. This will help users notice when a
given change requires several incremental compiler runs. The visibility of this implementation
detail is important to increase the sensibility for incremental compiler inefficiencies that can
be located and then fixed upstream.

Add resources to classpath by default (#796)

Thanks to @kubukoz, we have found that there
are several macro libraries that require resource directories of all the transitive dependencies
of a project to be present in the compilation classpath. One of these macro libraries was
scalaz-deriving.

To support this use case, bloop v1.2.2 adds these resource directories to the compilation
classpath by default.

Use bloop server via launchd in macOS (#786)

The launcher executed by brew services was not using bloop server but blp-server directly.
This was an oversight that is now fixed in v1.2.2, together with some more changes to ensure that
bloop server picks up correctly jvm options specified in $BLOOP_INSTALLATION_DIR/.jvmopts. In
macOS systems, the bloop installation directory is the cellar installation directory for bloop,
usually symlinked from /usr/local/bin/bloop.

bloop server will not fail if a server is already running

Unlike previous releases, bloop server now exits successfully if a server is already running.
Given the increasing use of the launcher in build integrations, this change aims to avoid
confusing errors that users could get when managing the lifecycle of the server manually via
their custom service management software (brew services, systemd, desktop entries, etc).

Fix handling of unicode characters in nailgun environment variables (scalacenter/nailgun#9)

Thanks to @marek1840, the python client should not fail if a
unicode character is present in an environment variable of your terminal.

Contributors 👥

According to git shortlog -sn --no-merges v1.2.1..v1.2.2, 2 people contributed to this v1.2.2
release: Jorge Vicente Cantero, marek1840.

v1.2.1

bloop v1.2.1 🏄

Upgrade guide 🔌

This section describes the upgrade steps. If you don't have bloop installed, please read
the installation instructions instead.

If you're on macOS, upgrade to the latest version with:

$ brew upgrade scalacenter/bloop/bloop
$ brew services restart bloop

If you're on Windows using scoop, upgrade to the latest version with:

$ scoop upgrade bloop
$ bloop ng-stop
$ // Start the server as you usually do (via systemd, manually, desktop services)

Otherwise, run:

$ curl -L https://github.com/scalacenter/bloop/releases/download/v1.2.1/install.py | python
$ bloop ng-stop
$ // Start the server as you usually do (via systemd, manually, desktop services)

Read the complete installation instructions in our Installation page.

Highlights 📚

v1.2.1 is mostly a bugfix release.

Clear bsp diagnostics earlier (#782)

Bloop's build server now clears diagnostics incrementally at the end of every incremental compiler cycle.

Document shell completion setup and use in macOS (#781)

If shell completions don't work for your macOS system, follow the Homebrew installation instructions
and jump to the completions section that links to the Homebrew guide to set up Homebrew-installed
completions.

Fixes 🐛 🔨

1. Use of transactional class file manager by default
2. Make the launcher work for v1.2.0 and not only v1.1.2

Contributors 👥

According to git shortlog -sn --no-merges v1.2.0..v1.2.1, 1 people contributed to this v1.2.1
release: Jorge Vicente Cantero.

v1.2.0

bloop v1.2.0 🏄

Upgrade guide 🔌

This section describes the upgrade steps. If you don't have bloop installed, please read
the installation instructions instead.

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

$ brew upgrade scalacenter/bloop/bloop
$ brew services restart bloop

If you're on Windows using scoop, upgrade to the latest version with:

$ scoop upgrade bloop
$ bloop ng-stop
$ // Start the server as you usually do (via systemd, manually, desktop services)

Otherwise, run:

$ curl -L https://github.com/scalacenter/bloop/releases/download/v1.2.0/install.py | python
$ bloop ng-stop
$ // Start the server as you usually do (via systemd, manually, desktop services)

Read the complete installation instructions in our Installation page.

Highlights 📚

New bloop launcher

Bloop v1.2.0 features a launcher (:rocket:), which is a core component responsible for:

1. Managing the bloop installation and server execution.
2. Establishing a bsp connection when a server is running.

The bloop launcher is a response to the reticency of depending on bloop because it needs to be
installed globally. Developer tools that want to use bloop either via BSP or CLI can depend on and
run the launcher (a ~112KB jvm artifact) to install and get a working build server in the background
out-of-the-box, getting an automatic setup in their users' machines.

The Launcher Reference page documents
the inner workings of the launcher and explains how to interact with it.

Compile, test and run several projects in one command (#772)

The compile, test and run actions now take several projects as arguments to run an action for
several projects in one go. For example, compile foo, bar and baz with:

→ bloop compile foo bar baz
Compiling foo (1 Scala source)
Compiled foo (290ms)
Compiling bar (1 Scala source)
Compiled bar (455ms)
Compiling baz (1 Scala source)
Compiled baz (229ms)

This feature comes in handy when you have several independent subgraphs inside the same build. The
Quickstart page documents the above behaviour.

Support --cascade in compile and test (#773)

The --cascade flag in a compile invocation allows you to change the public signature of a project
(say, foo) and have bloop compile all the transitive projects depending on foo to detect
compilation errors. When added to any test invocation, bloop will:

1. trigger the compilation of foo and all projects depending on foo (with their dependencies)
2. run tests of foo and all projects depending on foo (without their dependencies)

Using --cascade is a powerful trick to compile or run the tests of all projects that could be
possibly affected by a change in a project. As this is a common use case, --cascade aims to
simplify its use. This feature is fully documented by the
Quickstart page.

Cancel compilation

Compile cancellation was not yet supported by bloop and v1.2.0 fixes it. Just as the cancellation
of test or run, every time the user presses Ctrl+C in the middle of a
compilation command or a bsp client sends a cancel request, bloop will cancel the compilation
gracefully.

It's highly recommended to be on the last Scala 2.12.8 release to get more predictable and quick
cancellations.

Pass jvm options to test and run (#769)

Bloop v1.2.0 takes extra arguments prefixed with -J and positioned after -- and passes them to
the underlying virtual machine running an application or executing tests. Fixed by

Pass jvm options to the bloop server

Passing jvm options to the bloop server was possible but complicated in previous versions. v1.2.0
simplifies the handling of jvm options and supports configuring the virtual machine running bloop
via two mechanisms:

1. Arguments to bloop server prefixed with -J.
2. A .jvmopts file in the bloop installation directory which is read by bloop server. This is
   the recommended way to pass jvm options to the server as it's reproducible and easy to know
   what options the server was run with.

The following section documents the handling of jvm options by bloop server.

New documentation for the Build Server 📘

The Build Server reference page is a
new addition to our docs that gives an overview of what the build server is, how it can be started,
how it's installed and how it can be managed. It also contains information about how to pass JVM
options to the server.

It's recommended to read the Build Server
Reference even if you are a seasoned
bloop user.

Fixes 🐛 🔨

1. Clear diagnostics via BSP if files with problems don't exist anymore
2. Bump up supported mill versoin to v0.3.5
3. Run bloop from different disks in Windows
4. Provide autocompletions for -o and --only test invocations
5. Fix compilation of java-only projects when no scala instance is provided

Contributors 👥

According to git shortlog -sn --no-merges v1.1.2..v1.2.0, 5 people contributed to this v1.2.0
release: Jorge Vicente Cantero, tanishiking, Daniel Karch, Dario Abdulrehman and Josep Prat.

bloop v1.1.2

Install v1.1.2 🍬

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

$ brew upgrade scalacenter/bloop/bloop
$ brew services restart bloop

Otherwise, run:

$ curl -L https://github.com/scalacenter/bloop/releases/download/v1.1.2/install.py | python
// and restart the server

Read the complete installation instructions in our Installation page.

Highlights 📚

The v1.1.2 release is mostly a bugfix release fixing some installation problems.

Fixes in installation

1. Configure a scoop-based installation for Windows Powershell users.
2. Improve the ergonomics of Windows CMD users.
3. Fix several bugs with the installation script and the nailgun script.
4. Fix a bug in the build when running gradle in Windows.
5. Improve the UX of the installation page by persisting the choices to the session storage.

Check the PR introducing these changes here.

Handling recursive dependencies gracefully

See scalameta/metals#396 for the issue that triggered work on this area. Even
if recursive dependencies is a fatal error for bloop, we still handle
gracefully and connect successfully during a bsp connection. Builds that have
problems will get:

1. An empty response to workspace/buildTargets.
2. A build/showMessage per every error found.

Contributors 👥

According to git shortlog -sn --no-merges v1.1.1..v1.1.2, 1 people contributed to this
v1.1.2 release: Jorge Vicente Cantero.

bloop v1.1.2-M1

Merge pull request #758 from scalacenter/topic/weak-cyclic-dependency…