v1.4.1

bloop v1.4.0

Bloop v1.4.1 is identical to v1.4.0 but makes Bloop work on machines that use
Java 8 as their default Java version.

Merged pull requests

Here's a list of all of the PRs merged:

• Release artifacts with Java 8, not Java 11 #1278

v1.4.0

bloop v1.4.0

This release only works for Java 11 users (see this ticket). This bug is fixed in 1.4.1, so upgrade!

Bloop v1.4.0 is the culmination of a lot of work during the past months. While
some users have been benefiting from these features and bug fixes for a while
because Metals has been updating its Bloop version often, these release notes
offer an exhaustive description of all of the changes since v1.3.5.

It is strongly recommended to upgrade to bloop v1.4.0!

Features

New installation, bloopgun and dropping Python support

Our previous CLI was written in Python, based on the Nailgun python CLI. This
CLI required the user to install Python in the machine and had some issues such
as reliability problems and lack of a way of starting the bloop server
automatically in the background.

bloopgun is a new Scala-based CLI that replaces the previous Python CLI.
Bloopgun is built on [snailgun] and compiles to GraalVM in supported
architectures (Windows support is not there yet).

This release also changes the installation methods that Bloop provides to
clients. From now on, the recommended way to install bloop is through coursier install, only available in the latest coursier versions. It's recommended you
upgrade to the latest.

Additional installation resources such as Systemd files or brew services are
no longer installed by Bloop. More details about this can be found in this
ticket.

Shaded launcher and bloopgun

To avoid problems downstream, bloopgun and the launchers responsible for
starting bloop in the background are shaded to avoid causing dependency issues.

Fixed numerous problems with compile invalidations

This release fixes some important compile invalidations issue that have popped
up over the course of this past months. These issues could cause
ClassNotFoundExceptions or failed compilations in some corner cases. v1.4.0
fixes all known issues in this area, providing a better experience to those
users that have run into these problems.

Support for Hydra, a parallel Scala compiler

Mirco Dotta has added support for Hydra in Bloop v1.4.0. Hydra is a parallel
Scala compiler, it's created and maintained by [Triplequote]. Triplequote
customers should now be able to use Bloop in their development workflows,
bringing the best of parallel Scala compilation and incremental, fast compilers
by Bloop.

Experimental support in sbt-bloop to offload compilation to Bloop.

Bloop and sbt-bloop support offloading compilation from build tools. This
support added sbt-bloop with the capability of offloading compilation to Bloop,
so that compilations triggered from sbt or build clients such as IntelliJ or
Metals would be shared.

This feature is still experimental because there are some bugs that need to be
addressed. Only people willing to report bugs and help iron out this feature
are welcome to try it out now.

Improved tracing support via workspace settings

Bloop v1.4.0 has support for configuring tracing settings at a workspace
level thanks to [Win Wang][wiwa]. You can add these new settings under
.bloop/bloop.settings.json. The default tracing settings are:

{
  "traceSettings": {
    "serverUrl": "",
    "debugTracing": false,
    "verbose": false,
    "localServiceName": "",
    "traceStartAnnotation": "",
    "traceEndAnnotation": ""
  }
}

Debugging support via DAP

Bloop supports the [Debug Adapter protocol][dap] and exposes it to clients such
as Metals, so that build clients can debug tests or main applications in your
build. Implementation of this feature was a joint effort of many people, lead
by [Marek Żarnowski][marek].

Source glob support and changes to the bloop configuration format

Bloop now supports source globs in the bloop configuration file so that build
tools such as Pants or Bazel can represent their targets in terms of Bloop
configuration files. Check the following file for an up-to-date JSON Schema of
the bloop configuration file.

Runtime performance improvements

Bloop has been tested in large 1M+ codebases over the past months and we have
landed several changes to improve the runtime performance of Bloop in several
key parts of the developer experience. Bloop v.1.4.0 is faster and more
reliable after these changes.

Support for concurrent CLI sessions

Despite the fact that Bloop has had support for concurrent BSP and CLI sessions
for a while, Bloop didn't support concurrent CLI sessions until recently (e.g.
bloop run foo-web in one terminal, and bloop test foo-web -o mytest.Bar in
another one).

Support for Scala.js 1.0

Bloop v1.4.0 supports the latest Scala.js 1.0 release thanks to [Tim
Nieradzik][tindzk]. This release also includes some linking improvements.

Export improvements in build tools such as Gradle and sbt

We have landed several changes to improve build tool export in both Gradle
and sbt. To just name a few highlights, gradle-bloop supports now Gradle
6.0+ and sbt supports running a project from its project working directory
instead of the sbt build working directory.

Improved IntelliJ integration

Latest IntelliJ 2020.1.1 has significantly improved BSP and Bloop support, so
using Bloop with IntelliJ becomes easier and more reliable than before.

Support for global Bloop options

Users can now configure the options that the JVM options the bloop server
should use when starting up in $HOME/.bloop/bloop.json. See the online
documentation here.

Merged pull requests

Here's a list of all of the PRs merged:

• Support globs in file watching [#1269]
• Don't consider CLI classes directory an orphan directory [#1266]
• Upgrade Zinc version [#1265]
• Add workpace settings for Zipkin traces [#1262]
• Force source generation for cached 'sbt bloopGenerate' [#1261]
• Support links in path to javac [#1258]
• Register Scala generated class files before compiling Java [#1254]
• Make sure we use all the settings that already exist in the project [#1253]
• Make bloop about and bloop help always succeed [#1252]
• Use runtime classpaths in Gradle [#1250]
• Swap classpath and resources arguments [#1248]
• Use coursier install bloop in installation methods [#1246]
• Fixed providing jvm options in DAP [#1245]
• Support runtime classpath for JVM projects [#1244]
• Change zipkin URL in docs [#1241]
• Implement jvmRunEnvironment endpoint [#1239]
• Update various typos and metals docs [#1238]
• Increase default stack size to 4m [#1236]
• Fix a couple typos in the sbt section [#1235]
• Add Scala.js 1.0 support [#1234]
• Make jvmTestEnvironment's classpath URI-formatted [#1232]
• Add additional system properties for customizing zipkin traces [#1231]
• Report test projects without test frameworks [#1230]
• Fix build export installation step [#1227]
• Don't parse --help from Bloopgun [#1225]
• Remove unnecessary TraceContext creation for root span [#1223]
• Add dotty support to gradle plugin [#1222]
• Update documentation for IntelliJ BSP integration [#1221]
• Use correct working directory in BSP buildTarget/jvmTestEnvironment [#1216]
• Report error when refreshProjectsCommand fails [#1215]
• Add buildTargets/jvmEnvironment endpoint [#1214]
• Bump Hydra version for tests to 2.2.2 [#1213]
• Add tags to Bloop configuration [#1212]
• Hide fine-grained Zipkin traces behind system property [#1211]
• Improve docs and landing page [#1209]
• Add sbt scripted test for hydra sbt integration [#1208]
• Don't create the hydra.license file for PRs external to the repo [#1207]
• Fix bugs with non-stable CLI classes directories [#1206]
• Respect global configuration in $HOME/.bloop/bloop.json [#1203]
• Don't match on hidden source files [#1202]
• Fixes resource loading issue [#1199]
• Add missing scala-xml dependency in shaded launcher [#1198]
• Fallback to java home if it was not available on PATH [#1196]
• Allow regenerating bloop project data with external tool [#1195]
• Add debug sampling flag option for Zipkin traces [#1191]
• Fix hydra integration and make tests succeed [#1190]
• Include jvmTestEnvironmentProvider in build server capabilities [#1185]
• Add support for packagePrefix [#1183]
• Add new "sourcesGlobs" field to Bloop JSON configuration [#1176]
• Use right working directory to run app or tests from sbt [#1175]
• Add default -Xss1m compiler option [#1174]
• Fix error checking blacklisted versions [#1173]
• Add munit framework to default frameworks [#1172]
• Use dynverSeparator as recommended in sbt-dynver readme [#1171]
• Replace plus sign + with minus - in version number [#1170]
• Add BSP endpoint to query jvm test environment [#1166]
• Add options for Dotty to create semanticDB when Metals is present [#1165]
• URL-encode file paths for manifest jars [#1161]
• Make working directory configurable for bloopgun-cli [#1160]
• Fix an issue with non existing compileIncremental key [#1159]
• Report better errors if project loading fails [#1157]
• Create parents of invalidated symbolic links [#1156]
• Infer working directory from JVM -Duser.dir system property [#1154]
• Reduce noise in bloop-launcher console output [#1153]
• Pass arguments in to ammonite [#1152]
• Fix Windows drive letter handling in jar manifest [#1151]
• Silence error from _arguments:comparguments in completions [#1145]
• Ignore invalid proxy URIs on settings [#1141]
• Update minimum Gradle version to 4.3 and some fixes [#1137]
• Quote the full path for bloop in the generated bat file [#1131]
• Guard expensive log statem...

v1.4.0-RC3

bloop v1.4.0

Bloop v1.4.0 is the culmination of a lot of work during the past months. While
some users have been benefiting from these features and bug fixes for a while
because Metals has been updating its Bloop version often, these release notes
offer an exhaustive description of all of the changes since v1.3.5.

It is strongly recommended to upgrade to bloop v1.4.0!

Features

New installation, bloopgun and dropping Python support

Our previous CLI was written in Python, based on the Nailgun python CLI. This
CLI required the user to install Python in the machine and had some issues such
as reliability problems and lack of a way of starting the bloop server
automatically in the background.

bloopgun is a new Scala-based CLI that replaces the previous Python CLI.
Bloopgun is built on [snailgun] and compiles to GraalVM in supported
architectures (Windows support is not there yet).

This release also changes the installation methods that Bloop provides to
clients. From now on, the recommended way to install bloop is through coursier install, only available in the latest coursier versions. It's recommended you
upgrade to the latest.

Additional installation resources such as Systemd files or brew services are
no longer installed by Bloop. More details about this can be found in this
ticket.

Shaded launcher and bloopgun

To avoid problems downstream, bloopgun and the launchers responsible for
starting bloop in the background are shaded to avoid causing dependency issues.

Fixed numerous problems with compile invalidations

This release fixes some important compile invalidations issue that have popped
up over the course of this past months. These issues could cause
ClassNotFoundExceptions or failed compilations in some corner cases. v1.4.0
fixes all known issues in this area, providing a better experience to those
users that have run into these problems.

Support for Hydra, a parallel Scala compiler

Mirco Dotta has added support for Hydra in Bloop v1.4.0. Hydra is a parallel
Scala compiler, it's created and maintained by [Triplequote]. Triplequote
customers should now be able to use Bloop in their development workflows,
bringing the best of parallel Scala compilation and incremental, fast compilers
by Bloop.

Experimental support in sbt-bloop to offload compilation to Bloop.

Bloop and sbt-bloop support offloading compilation from build tools. This
support added sbt-bloop with the capability of offloading compilation to Bloop,
so that compilations triggered from sbt or build clients such as IntelliJ or
Metals would be shared.

This feature is still experimental because there are some bugs that need to be
addressed. Only people willing to report bugs and help iron out this feature
are welcome to try it out now.

Improved tracing support via workspace settings

Bloop v1.4.0 has support for configuring tracing settings at a workspace
level thanks to [Win Wang][wiwa]. You can add these new settings under
.bloop/bloop.settings.json. The default tracing settings are:

{
  "traceSettings": {
    "serverUrl": "",
    "debugTracing": false,
    "verbose": false,
    "localServiceName": "",
    "traceStartAnnotation": "",
    "traceEndAnnotation": ""
  }
}

Debugging support via DAP

Bloop supports the [Debug Adapter protocol][dap] and exposes it to clients such
as Metals, so that build clients can debug tests or main applications in your
build. Implementation of this feature was a joint effort of many people, lead
by [Marek Żarnowski][marek].

Source glob support and changes to the bloop configuration format

Bloop now supports source globs in the bloop configuration file so that build
tools such as Pants or Bazel can represent their targets in terms of Bloop
configuration files. Check the following file for an up-to-date JSON Schema of
the bloop configuration file.

Runtime performance improvements

Bloop has been tested in large 1M+ codebases over the past months and we have
landed several changes to improve the runtime performance of Bloop in several
key parts of the developer experience. Bloop v.1.4.0 is faster and more
reliable after these changes.

Support for concurrent CLI sessions

Despite the fact that Bloop has had support for concurrent BSP and CLI sessions
for a while, Bloop didn't support concurrent CLI sessions until recently (e.g.
bloop run foo-web in one terminal, and bloop test foo-web -o mytest.Bar in
another one).

Support for Scala.js 1.0

Bloop v1.4.0 supports the latest Scala.js 1.0 release thanks to [Tim
Nieradzik][tindzk]. This release also includes some linking improvements.

Export improvements in build tools such as Gradle and sbt

We have landed several changes to improve build tool export in both Gradle
and sbt. To just name a few highlights, gradle-bloop supports now Gradle
6.0+ and sbt supports running a project from its project working directory
instead of the sbt build working directory.

Improved IntelliJ integration

Latest IntelliJ 2020.1.1 has significantly improved BSP and Bloop support, so
using Bloop with IntelliJ becomes easier and more reliable than before.

Support for global Bloop options

Users can now configure the options that the JVM options the bloop server
should use when starting up in $HOME/.bloop/bloop.json. See the online
documentation here.

Merged pull requests

Here's a list of all of the PRs merged:

• Support globs in file watching [#1269]

• Don't consider CLI classes directory an orphan directory [#1266]

• Upgrade Zinc version [#1265]

• Add workpace settings for Zipkin traces [#1262]

• Force source generation for cached 'sbt bloopGenerate' [#1261]

• Support links in path to javac [#1258]

• Register Scala generated class files before compiling Java [#1254]

• Make sure we use all the settings that already exist in the project [#1253]

• Make bloop about and bloop help always succeed [#1252]

• Use runtime classpaths in Gradle [#1250]

• Swap classpath and resources arguments [#1248]

• Use coursier install bloop in installation methods [#1246]

• Fixed providing jvm options in DAP [#1245]

• Support runtime classpath for JVM projects [#1244]

• Change zipkin URL in docs [#1241]

• Implement jvmRunEnvironment endpoint [#1239]

• Update various typos and metals docs [#1238]

• Increase default stack size to 4m [#1236]

• Fix a couple typos in the sbt section [#1235]

• Add Scala.js 1.0 support [#1234]

• Make jvmTestEnvironment's classpath URI-formatted [#1232]

• Add additional system properties for customizing zipkin traces [#1231]

• Report test projects without test frameworks [#1230]

• Fix build export installation step [#1227]

• Don't parse --help from Bloopgun [#1225]

• Remove unnecessary TraceContext creation for root span [#1223]

• Add dotty support to gradle plugin [#1222]

• Update documentation for IntelliJ BSP integration [#1221]

• Use correct working directory in BSP buildTarget/jvmTestEnvironment [#1216]

• Report error when refreshProjectsCommand fails [#1215]

• Add buildTargets/jvmEnvironment endpoint [#1214]

• Bump Hydra version for tests to 2.2.2 [#1213]

• Add tags to Bloop configuration [#1212]

• Hide fine-grained Zipkin traces behind system property [#1211]

• Improve docs and landing page [#1209]

• Add sbt scripted test for hydra sbt integration [#1208]

• Don't create the hydra.license file for PRs external to the repo [#1207]

• Fix bugs with non-stable CLI classes directories [#1206]

• Respect global configuration in $HOME/.bloop/bloop.json [#1203]

• Don't match on hidden source files [#1202]

• Fixes resource loading issue [#1199]

• Add missing scala-xml dependency in shaded launcher [#1198]

• Fallback to java home if it was not available on PATH [#1196]

• Allow regenerating bloop project data with external tool [#1195]

• Add debug sampling flag option for Zipkin traces [#1191]

• Fix hydra integration and make tests succeed [#1190]

• Include jvmTestEnvironmentProvider in build server capabilities [#1185]

• Add support for packagePrefix [#1183]

• Add new "sourcesGlobs" field to Bloop JSON configuration [#1176]

• Use right working directory to run app or tests from sbt [#1175]

• Add default -Xss1m compiler option [#1174]

• Fix error checking blacklisted versions [#1173]

• Add munit framework to default frameworks [#1172]

• Use dynverSeparator as recommended in sbt-dynver readme [#1171]

• Replace plus sign + with minus - in version number [#1170]

• Add BSP endpoint to query jvm test environment [#1166]

• Add options for Dotty to create semanticDB when Metals is present [#1165]

• URL-encode file paths for manifest jars [#1161]

• Make working directory configurable for bloopgun-cli [#1160]

• Fix an issue with non existing compileIncremental key [#1159]

• Report better errors if project loading fails [#1157]

• Create parents of invalidated symbolic links [#1156]

• Infer working directory from JVM -Duser.dir system property [#1154]

• Reduce noise in bloop-launcher console output [#1153]

• Pass arguments in to ammonite [#1152]

• Fix Windows drive letter handling in jar manifest [#1151]

• Silence error from _arguments:comparguments in completions [#1145]

• Ignore invalid proxy URIs on settings [#1141]

• Update minimum Gradle version to 4.3 and some fixes [#1137]

• Quote the full path for bloop in the generated bat file [#1131]

• Guard expensive log statements against logger.isVerbose [#1127]

• Require collection field types in jsoniter codecs [#1125]

• Sync up with Zinc to get Dotty rendered problems [#1124]

• Disable shared sbt-bloop classes dirs when not offloading [#1123]

• Fix spurious ClassNotFoundExceptions [#1122]

• Respect --no-color flag [#1120]

• Use MANIFEST jar to run commands that exceed OS li...

v1.4.0-RC1

bloop v1.4.0-RC1

1.4.0-RC1 is a temporary release to test all of the changes that have
happened since 1.3.4 and 1.3.5. It fixes many bugs, improves overall
performance and adds support for user-facing features such as debugging and
the experimental "offloading compilation from sbt".

v1.3.4

bloop v1.3.4

Release notes for 1.3.4 are to come soon.

v1.3.3

bloop v1.3.3

Release notes for 1.3.3 are to come soon.

v1.3.2

bloop v1.3.2

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

Bloop v1.3.2 is a bugfix release for v1.3.1.

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.2/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.

Fixed directory resource leak

v1.3.0 had a piece of code listing directories via Files.list() that
ended up not freeing up open file pointers. Over a long bsp session, these
open file pointers would add up and eventually lead to fatal exceptions in
systems such as macOS.

A wrong git push tag of v1.3.1 made this fix not available in master,
despite the fact that it was merged, so v1.3.2 is the release containing
the fix that closes the resources opened by Files.list().

Contributors 👥

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

v1.3.1

bloop v1.3.1

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

Bloop v1.3.1 is a bugfix release for v1.3.0.

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.1/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.

Fixed Ammonite integration in CLI client

v1.3.0 added an Ammonite integration in Bloop. Every time bloop console is run, bloop compiles the project and then creates an Ammonite REPL
session. This integration required the cooperation of the nailgun script that
ended up misfunctioning due to a git revert error. The bug would print the Ammonite command to run but would not actually run it.

A workaround would be to run sh -c $(bloop console $PROJECT), however
v1.3.1 fixes the CLI client so that this workaround is no longer needed.

Contributors 👥

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

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...