jvican released this
May 16, 2018
· 8 commits to master since this release
If you're on Mac OS X, upgrade to the latest version with:
$ brew install scalacenter/bloop/bloop
$ curl -L https://github.com/scalacenter/bloop/releases/download/v1.0.0-M10/install.py | python
Read the complete instructions in our Installation page.
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):
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.
$ systemctl --user status bloop
$ systemctl --user start bloop
$ systemctl --user stop bloop
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
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.
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.
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.
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.
Run and test are now cancelable via CTRL-C. When one of these tasks is cancelled, Bloop gracefully handles the shutdown of the processes.
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.
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 test frontend -o bloop.tasks.RunTasksSpec -- -z "*CancelNeverEnding*"
Bloop cannot support test options for several frameworks because they are framework dependent.
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.
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).
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.
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.
When the server is not started, autocompletions don't work. This change will detect this scenario and only propose the server completion.
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.
Waiting for source changes... (press C-c to interrupt)
Command flags may have more than one word (for example, --config-dir). This fix hides the implementation detail of Bloop and shows the autocompletion as it is expected, instead of showing the source name (--configDir).
Our previous autocompletion engine was assuming that all our commands take projects as arguments, but not of them do. Those that don't were not being autocompleted with the flags that they take. In this new release, completions work for commands like bloop configure.
We welcome akka/akka to our community build. Given the impact of this project in our ecosystem, and how complex the build is, we consider it a success that bloop now fully supports the compilation of the project.
Builds in sbt can define dependencies across configurations, but these were poorly handled by bloop v1.0.0-M9 and previous versions. The new version makes a best effort to detect these dependencies across compile and test configurations.
Because of some sbt pecularities, the sbt bloop plugin can have naming conflicts with other global or local sbt plugins installed in a given build. This commit fixes an incompatibility with the sbt-metals plugin which defined a Compat trait that was being picked up instead of the one that Bloop defines.
According to git shortlog -sn --no-merges v1.0.0-M9..1.0.0-M10, 7 people contributed to this release: Jorge Vicente Cantero, Rubén Berenguel Montoro, Paweł Bartkiewicz, Alexey Alekhin, Jon Pretty and Justin Kaeser.
git shortlog -sn --no-merges v1.0.0-M9..1.0.0-M10
The Bloop team at the Scala Center is also proud of welcoming Paweł and Ruben to our team! Their contributions have been great to make this release happen. Thank you all
bloopoid released this
Apr 6, 2018
· 18 commits to master since this release
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.
$ curl -L https://github.com/scalacenter/bloop/releases/download/v1.0.0-M9/install.py | python
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.
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.
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 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.
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.
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.
bloopoid released this
Mar 28, 2018
· 4 commits to master since this release
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.
$ curl -L https://github.com/scalacenter/bloop/releases/download/v1.0.0-M8/install.py | python
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.
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.
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.
bloop test foo -f com.my.TestSuite
bloop test foo -o com.my.TestSuite
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.
bloop test foo -o com.myTestSuite -o ch.epfl.scala.CoolSuite
The sbt bloop plugin has several improvements over the plugin in M7:
bloopAggregateSourceDependencies in Global := true
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
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.
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.
bloopoid released this
Mar 15, 2018
This is the seventh milestone of Bloop. This release focuses on improving the user experience and fixes several important bugs.
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.
@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
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.
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.
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.
To install the latest version of Bloop, you can either use Homebrew:
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
bloopoid released this
Mar 13, 2018
· 37 commits to master since this release
This is the sixth milestone of Bloop.
bloopoid released this
Mar 8, 2018
· 6 commits to master since this release
This is the fifth milestone of Bloop. The release focuses on hot fixes, usability improvements and a major nailgun upgrade.
bloopoid released this
Mar 2, 2018
This is the fourth milestone of Bloop. Please read our README to learn more about Bloop.
bloopoid released this
Feb 10, 2018
This is the third milestone of Bloop. Please read our README to learn more about Bloop.
Duhemm released this
Jan 30, 2018
· 65 commits to master since this release
This is the first milestone of Bloop. Please read our README to learn more about Bloop.