Releases: scalacenter/bloop
bloop-frontend v1.0.0-M10
Install the latest release 🍬
If you're on Mac OS X, upgrade to the latest version with:
$ brew install scalacenter/bloop/bloop
Otherwise, run:
$ curl -L https://github.com/scalacenter/bloop/releases/download/v1.0.0-M10/install.py | python
Read the complete instructions in our [Installation page][installation instructions].
Highlights 📚
Build Server Protocol
This is an special section updating on the latest developments of
BSP (Build Server Protocol), an
initiative led by [@jvican] and others at the Scala Center to bring better build
tool support to all the IDEs and editors.
Over the past weeks, we have been working with [Justin Kaeser][jastice], from the
IntelliJ team, on a proof-of-concept BSP integration between IntelliJ and
Bloop, with the goal of supporting other future clients like sbt and Bazel,
among others.
We updated the Scala community on these efforts in our Scalasphere 2018
talk titled "Build Server Protocols and new IDEAs"
which will be available online soon. At the talk, we gave a demo of Bloop
integrating with IntelliJ over the protocol and providing fast "import
project" capabilities (usually in the order of milliseconds for small to
medium projects, and < 10 seconds for big projects). These capabilities
replace the slow "sbt import" features of the Scala plugin.
We plan on developing this prototype further over the next weeks and getting
it ready to a state in which can be used by the whole Scala community. To do
so, this release includes an almost full implementation of the BSP protocol
(note that it will still go through some changes in the next weeks):
- Continue the BSP implementation.
- Add
ScalBuildTarget
and project dependencies to BSP. - Use range positions if available.
- Report compilation logs via
publishDiagnostics
. - Support efficient sequential command compilation.
- Notify client when the server starts listening.
Installation improvements 🔧
Integration with systemd (by [@tues])
Systemd is a Linux/BSD system manager that allows users to configure the
lifetime of services. As systemd is a perfect way to run your Bloop server on
the background only once, @tues has added support
for it, together with excellent documentation available in our
website.
Sneak peek:
$ systemctl --user status bloop
$ systemctl --user start bloop
$ systemctl --user stop bloop
Integration with desktop entries (by [@tues])
Desktop entries are another common mechanism to control the execution of services.
Bloop now integrates with it so that users that don't have systemd installed in their
system have an alternative way of managing the bloop server.
Complete instructions to set them up are available in the desktop entry
section of our
website
Use python3 in homebrew formula (by [@Duhemm])
While our installation scripts are python 2 and python 3 compatible, some
homebrew installations don't seem to like that bloop is executed by running
python 2. This change makes Python 3 the default runtime to execute our
installation scripts in OSX.
Upgrade soc/directories-jvm
to match Coursier's version (by [@jvican])
Bloop is run via coursier launch
, and that's why our installation script
installs coursier in a script called blp-coursier
under (typically) the
$HOME/.bloop
directory.
However, there have been some proguard misbehaviours with the latest coursier
releases, where its dependencies were leaking. One of these dependencies is
soc/directories-jvm
, which we also depended on. This commit fixes an binary
incompatibility between the version that Coursier used and the one that Bloop
uses.
Features 🏗️
Support Dotty projects (by [@jvican] and [@Duhemm])
Bloop now supports Dotty projects. If you
have an sbt-configured Dotty project and you export it with Bloop, Bloop will
be able to compile, test and run your project.
Support connectInput
for run applications (by [@jvican])
connectInput
is an sbt setting that allows forked applications to reuse the
standard input of the process that launched them. Bloop now supports this
setting by default and any text (ending with new lines) that you enter in your
shell will be received by the application. This translated to
java.util.Scanner.nextLine()
working perfectly.
Note that whatever goes into standard input will need to end in a new line to
be sent to the process running on the background. This is a limitation imposed
by Nailgun.
Make run and test cancelable (by [@jvican])
Run and test are now cancelable via CTRL-C
. When one of these tasks is cancelled,
Bloop gracefully handles the shutdown of the processes.
Add more efficient process implementation via NuProcess (by [@jvican])
NuProcess is a great library to manage system processes in an efficient way.
The latest version of Bloop uses it under the hood, which means that the
execution of many system process will be as efficient as it can be.
Support test options via the CLI (by [@jvican])
Test options can now be passed from the CLI if and only if one test framework
is detected. This happens when your build only supports one test framework or
when you are running a concrete filtered test that uses a single test
framework.
For example, bloop test frontend -o bloop.tasks.RunTasksSpec -- -z "*CancelNeverEnding*"
runs the RunTaskSpec
JUnit test and passes in the test options (note the --
) to the
JUnit test framework. In this case, the test options tell the test runner to only
run the methods that match the regex *CancelNeverEnding*
.
Bloop cannot support test options for several frameworks because they are framework dependent.
Allow sources
to contain both source directories and files (by [@jvican])
The field sources
in our configuration file only supported source directories.
However, there are some build tools —like Bazel— that do not know what source
directories are mapped to a target, they only know the source files.
In the spirit of being build-tool-agnostic, Bloop now supports both source
files and source directories. Note that if a new source file is added outside
of an existing source directory, you will need to add it to the json file manually or
export your build tool again.
Persist analysis files on the background (by [@jvican])
One of the benefits of being a server is that Bloop doesn't need to write the analysis
files generated by the incremental compiler to disk in every compilation. Therefore,
Bloop keeps them in memory.
However, if the server is killed, these analysis files are gone. This improvement
makes Bloop capable of writing the analysis file in parallel on the
background when the user has exit the session. By doing this, we keep
compilation fast because we don't need to wait until the server has written
all the analysis files (which can be in the order of ~500MB in big projects).
Bugfixes 🐛
Make console
work again by enabling -Xnojline
(by [@tues])
Bloop uses nailgun under the hood, and therefore all activity in the input
stream needs to go through it. jline
doesn't like this whole level of
indirection, and therefore for console to work we need to pass in -Xnojline
as a Scala console option.
For an excellent analysis of what is going on, check the original bug
report.
Usability improvements
Speed up the project load (by [@jvican])
The first time you do bloop about
or bloop projects
in a folder, Bloop loads up
the build. This process may take time because the analysis files need to be read from
disk for every module that is defined.
The new v1.0.0-M9
release is significantly faster doing so because the project load
happens in parallel. This reduces the time Bloop takes to load the project from 2s for
the bloop build to 450ms. Bigger projects will see even bigger load speedups.
Autocomplete to bloop server
when server is not started (by [@propensive])
When the server is not started, autocompletions don't work. This change
will detect this scenario and only propose the server
completion.
Add file watching logs on every iteration (by [@rberenguel])
Bloop will now show the logs Waiting for source changes... (press C-c to interrupt)
in every file watching iteration. This highlights the fact that
the action has already been completed and Bloop is waiting for file changes.
Display multi-word flag autocompletions with kebab style (by [@rberenguel])
Command flags may have more than one word (for example, `--...
bloop-frontend v1.0.0-M9
Bloop v1.0.0-M9
Bloop is getting closer and closer to 1.0.0! 🚶♂️
This milestone of Bloop includes changes to the configuration files; you'll need to re-generate
your configuration files if you used a previous version of Bloop. See the installation
instructions.
Install the latest release 🍬
If you're on Mac OS X, upgrade to the latest version with:
$ brew install scalacenter/bloop/bloop
Otherwise, run:
$ curl -L https://github.com/scalacenter/bloop/releases/download/v1.0.0-M9/install.py | python
Read the complete instructions in our Installation page.
Highlights
Change configuration file to JSON 📝
Requires a complete regeneration of configuration files
The configuration file didn't have a well-specified format that could be reused
by external tools, was difficult to read and write and didn't allow the
representation of nested data structures. Java properties were flexible, but
didn't quite cut them as a good configuration file.
This release replaces the Java properties file with JSON configuration files,
accompanied of a JSON schema, accessible in The Configuration
Format docs. The docs display with docson
the json schema.
Bloop v1.0.0-M9 also includes the bloop-config
Scala artifact so that
external tools can read and write Bloop configuration files.
We hope that this format makes it easier to integrate with bloop.
Support for test options 🤺
Requires a complete regeneration of configuration files
Bloop now supports options for the test frameworks, and they can be specified
in the configuration file.
These options are framework specific. They specify excludes
and the test
arguments passed in to the test server initialization.
This new feature allows to fix a bug in JUnit test execution. The JUnit test
framework required the -z
defaults to show the test logs, and those defaults
are now visible in the configuration files and interpreted by bloop test
runner. #329 is now fixed.
Remove stale configuration files in sbt 🔨
Stale configuration files are configuration files for projects that have been
removed from the stock build tool after doing bloopInstall
. These
configuration files stay in the configuration directory if they are not removed
manually by the user. Their presence causes bloop to load them up and try to
compile projects that don't exist anymore. As a result, bloop now removes these
files if it detects that a project has been removed.
The configuration directory has been migrated to .bloop
🚀
Requires a complete regeneration of configuration files
The previous default configuration directory was .bloop-config
, which was
a misnomer given that bloop also stores the analysis files and the classes
directory within .bloop-config
.
This release makes .bloop
the new default one. Make sure you add it to your
.gitignore
file to avoid pushing the configuration files to your repository.
Use user nailgun environment to run and test projects 🔧
Bloop didn't expose the environment variables from the use site to the test or
main runners.
With this change, any environment variable that you update at the CLI use site
will be visible to Bloop, and therefore accessible in your test suites and main
classes.
Detect compile->test
and test->compile
dependencies 🕵️♂️
Generating configuration files for compile->test
and test->compile
configurations is common when you want the tests of a project to depend only on
the compile of a downstream project.
This release makes sbt-bloop recognize these dependencies and output the correct
dependencies.
bloop-frontend v1.0.0-M8
Bloop v1.0.0-M8
This is the eighth milestone of Bloop! 🎉
While we're working on ergonomics and making bloop easier to use by both users and build tools, this release is a hotfix of M7.
This milestone of Bloop includes changes to the configuration files; you'll need to re-generate
your configuration files if you used a previous version of Bloop. See the installation
instructions.
Install the latest release
If you're on Mac OS X, upgrade to the latest version with:
$ brew install scalacenter/bloop/bloop
Otherwise, run:
$ curl -L https://github.com/scalacenter/bloop/releases/download/v1.0.0-M8/install.py | python
Highlights
File watching improvement
In some cases, bloop could get hanging compilation processes caused by CTRL-C
while file watching a given project. These hanging processes could interfere with new spawned processes that used file watching too, and in some scenarios they would steal job from the main file watching process and compilation or testing wouldn't yield any output.
Such a bug is now fixed. We have experimented with file watching in several projects and confirmed it now works reliably.
Start the server with bloop server
You can now start the server from the bloop client with bloop server
. This improvement was suggested by both Olafur and Jon and has the benefits of not polluting the space for autocompletions and yet having an easy way to start it, without need to remember the weird blp-server
binary name.
Test filters are now accessible via --only
The old bloop test foo -f com.my.TestSuite
has been replaced by bloop test foo -o com.my.TestSuite
(-o
is named after --only
). This change brings more ergonomics and makes it intuitive for those users that are used to the testOnly
style in sbt.
If you want to specify more than one test filter, type several -o
arguments. Example: bloop test foo -o com.myTestSuite -o ch.epfl.scala.CoolSuite
.
Improvements to the sbt plugin
The sbt bloop plugin has several improvements over the plugin in M7:
- Support for source dependencies: if you use source dependencies, set
bloopAggregateSourceDependencies in Global := true
and runbloopInstall
.sbt-bloop
will then write all the configuration files to the same bloop config directory, and not in the base directories of the build of every sourcedep. sbt-bloop
is now less verbose when generating configuration files.- Workaround for missing
bloopInstall
autocompletion. Bloop works around a bug in sbt that doesn't autocompletes settings scoped globally.
Nailgun server exception is gone
You may have experienced that the nailgun server would throw non-fatal exceptions like:
Dec 12, 2017 12:40:41 PM com.martiansoftware.nailgun.NGInputStream$1 run
WARNING: Nailgun client read future was interrupted
java.lang.InterruptedException
at java.util.concurrent.FutureTask.awaitDone(FutureTask.java:404)
at java.util.concurrent.FutureTask.get(FutureTask.java:204)
at com.martiansoftware.nailgun.NGInputStream$1.run(NGInputStream.java:91)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
As reported in this ticket.
This new release fixes this issue, and now the server doesn't throw any exception. While this is not something important because the logs of the nailgun server should not be relevant, it cleans up logs and limits users' confusion whehn using Bloop.
Support for classpath options
Bloop now observes the classpathOptions
setting defined in sbt builds. This setting configures how the compilation classpath is constructed (whether to include the Scala compiler, automatically append the Scala standard library, etc.)
This change requires that configuration files are re-generated. The instructions for generating the configuration files can be found in the installation instructions.
bloop-frontend v1.0.0-M7
Bloop v1.0.0-M7
This is the seventh milestone of Bloop. This release focuses on improving the user experience and
fixes several important bugs.
Release highlights
Autocompletion for Bash and zsh
In order to make Bloop more enjoyable to use, we added command line completions for Bloop,
compatible with Bash and zsh. They are automatically installed when using Homebrew. For other
platforms, our installation instructions explain how to install the completion.
For details about the work, see #353.
Simpler installation
@valencik contributed a fix to our installation script, in order to make it compatible with both
Python 2 and 3. Thanks to his changes, the installation script now runs smoothly on all
configurations. The work happened in #343. Thanks @valencik 🎉 !
Improved sbt-bloop
sbt-bloop used to define a task called installBloop
, which has been renamed to bloopInstall
. The
reason for the renaming is to improve the discoverability of this task. For more details, see the
discussion in #341 and #346.
Better file watching
In some cases, the file watcher would trigger an action more than once for a single change. As a
result, we would sometimes get wrong results for compilation. The file watcher has been fixed so
that this doesn't happen again.
Support for listener has also been added, so that bloop knows when a client has disconnected and can
stop watching files. For more details, see #345.
Fixes and improvements to the task engine
After a compilation failure, for instance, Bloop would still try (and fail) to run a project. This
problem has been fixed by improvements to how different tasks are combined within Bloop. See #347
for all the details.
Install Bloop
To install the latest version of Bloop, you can either use Homebrew:
$ brew install scalacenter/bloop/bloop
For other systems, you can download and the installation script below, or copy paste the following
line in your terminal:
$ curl -L https://github.com/scalacenter/bloop/releases/download/v1.0.0-M7/install.py | python
bloop-frontend v1.0.0-M6
Bloop v1.0.0-M6
This is the sixth milestone of Bloop.
bloop-frontend v1.0.0-M5
Bloop v1.0.0-M5
This is the fifth milestone of Bloop. The release focuses on hot fixes,
usability improvements and a major nailgun upgrade.
bloop-frontend v1.0.0-M4
Bloop v1.0.0-M4
This is the fourth milestone of Bloop. Please read our README to learn more about Bloop.
bloop-frontend v1.0.0-M3
Bloop v1.0.0-M3
This is the third milestone of Bloop. Please read our README to learn more about Bloop.
Bloop v1.0.0-M1
Bloop v1.0.0-M1
This is the first milestone of Bloop. Please read our README to learn more about Bloop.