Skip to content

Releases: scalacenter/bloop

v1.4.0-RC1

18 Dec 16:33
126ee5a
Compare
Choose a tag to compare
v1.4.0-RC1 Pre-release
Pre-release

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

06 Oct 23:33
0740537
Compare
Choose a tag to compare

bloop v1.3.4

Release notes for 1.3.4 are to come soon.

v1.3.3

02 Oct 09:23
Compare
Choose a tag to compare

bloop v1.3.3

Release notes for 1.3.3 are to come soon.

v1.3.2

08 Jun 23:42
e473d88
Compare
Choose a tag to compare

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

08 Jun 21:26
da41649
Compare
Choose a tag to compare

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

06 Jun 19:45
21a1cdb
Compare
Choose a tag to compare

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.

A Zipkin instance with build traces from the akka/akka project

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

A Zipkin instance showing a detaild profile of a build trace from the akka/akka project

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

Read more

v1.3.0-RC1

04 Jun 16:21
c382eaf
Compare
Choose a tag to compare
v1.3.0-RC1 Pre-release
Pre-release

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.

A Zipkin instance with build traces from the akka/akka project

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

A Zipkin instance showing a detaild profile of a build trace from the akka/akka project

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

Read more

v1.2.5

22 Jan 23:48
39837db
Compare
Choose a tag to compare

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

21 Jan 14:56
f6868d2
Compare
Choose a tag to compare

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

17 Jan 09:31
10eb450
Compare
Choose a tag to compare

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.