bloopoid released this
Dec 13, 2018
· 2 commits to master since this release
If you're on Mac OS X, upgrade to the latest version with:
$ brew upgrade scalacenter/bloop/bloop
$ curl -L https://github.com/scalacenter/bloop/releases/download/v1.1.2/install.py | python
Read the complete installation instructions in our Installation page.
The v1.1.2 release is mostly a bugfix release fixing some installation problems.
Check the PR introducing these changes here.
See scalameta/metals#396 for the issue that triggered work on this area. Even if recursive dependencies is a fatal error for bloop, we still handle gracefully and connect successfully during a bsp connection. Builds that have problems will get:
According to git shortlog -sn --no-merges v1.1.1..v1.1.2, 1 people contributed to this v1.1.2 release: Jorge Vicente Cantero.
git shortlog -sn --no-merges v1.1.1..v1.1.2
bloopoid released this
Dec 5, 2018
$ curl -L https://github.com/scalacenter/bloop/releases/download/v1.1.1/install.py | python
Bloop has now a new website based on Docusaurus. The new website has simplified the installation sections and reorganized the structure to make it easier to read.
The new website is not yet finished but it's already an improvement over our old Kube-based website.
The homebrew installation doesn't fail anymore if users have both Java 8 and Java 11 installed. The fix consists in resolving the bloop server via coursier launch and finding the Java 8 home by using /usr/libexec/java_home in Mac OS.
The output of bloop about is more concise in v1.1.1, imitating that of build tools such as yarn.
According to git shortlog -sn --no-merges v1.1.0..v1.1.1, 1 people contributed to this v1.1.0 release: Jorge Vicente Cantero.
git shortlog -sn --no-merges v1.1.0..v1.1.1
bloopoid released this
Dec 3, 2018
· 5 commits to master since this release
$ brew install scalacenter/bloop/bloop
$ curl -L https://github.com/scalacenter/bloop/releases/download/v1.1.0/install.py | python
Bloop is a Scala build server and command-line tool to make the compile and test developer workflows fast and productive in a build-tool-agnostic way. Learn more about Bloop and its origins in this ScalaDays Berlin talk.
The new version of the protocol, a joint effort of Olafur Páll Geirsson (Scala Center), Justin Kaeser (JetBrains) and Jorge Vicente Cantero (Scala Center), simplifies client integrations, improves task notifications and diagnostics reporting, adds a new BSP connection protocol to discover BSP servers and polishes v1.0.0.
Despite the fact that there is not a stable BSP v2.0 release out yet, Bloop adds initial support for BSP v2.0.0-M2, which is also implemented by IntelliJ 2018.3.504 and Metals 0.2.3. This means you can use bloop v1.1.0 with both Metals and IntelliJ.
Full support for BSP 2.0 (for example, testing and running via the protocol) will soon be available in future bloop versions.
Build import and compiler diagnostics in Metals are powered by bloop v1.1.0. This release adds a lot of small usability and correctness fixes to make bloop a fitting server for Metals. Metals supports several editors (such as vim and Visual Studio Code) and has best-in-class bloop integration (for example, every time there is a change in an sbt build, Metals can ask you to reload the build and run bloopInstall automatically). Try out Metals here.
Build pipelining is a compilation performance technique to start the compilation of modules in a build before their dependencies have finished compilation. An experimental implementation of build pipelining has been pioneered and merged in bloop v1.1.0.
Build pipelining is not yet ready for mainstream use (incremental compilation is not supported yet).
However, v1.1.0 adds experimental support to allow bloop clients check compilation speedups with build pipelining. To benchmark build pipelining, bloop clean your project and add --pipeline to your bloop compile invocation. Clean and repeat the process to warm up the compiler as many times as the compilation numbers you have for raw compilation.
At the moment, build pipelining doesn't work with incremental compilation so it's not a great fit for day-to-day use. Improvements on this area are staged for the future.
Bloop compiles its community build successfully under build pipelining. The community build includes the following projects: apache/spark, lihaoyi/utest, scala/scala, ornicar/lichess, twitter/scalding, akka akka, twitter/finagle, sbt/sbt, twitter/algebird, twitter/scalatra, guardian/frontend, netflix/atlas and guardian/grid.
The results of build pipelining are positive but are not yet fully confirmed. Compilations of projects such as apache/spark, twitter/finagle and ornicar/lila give significant speedups. There are reasons to think future versions of bloop and Scala (2.12.8 and 2.13.0) will improve the performance of build pipelining. You can see that current results range from 0% to 32% compilation speedup.
When build pipelining is run on projects that define Java and Scala sources, build pipelining becomes more challenging. The current bloop implementation handles this transparently to the user and defaults on a reasonable policy that works in our current community build. The downside is that users don't have a lot of flexibility in using build pipelining and making sure it works in their project without source changes.
In next versions, this limitation will go away and there will be an explicit mechanism for users to control the order in which Java and Scala are compiled and its intra-build dependencies.
Thanks to #706, contributed by @tindzk and @jvican, bloop v1.1.0 can now test Scala.js 0.6.x and 1.x projects and link projects using CommonJS modules. After this change, the only missing bit is to test Scala Native projects.
Thanks to Daniel Silva and Daniel Vigozovsky, bloop features a Gradle installation. To learn how to use bloop with Gradle, head to the installation instructions.
According to git shortlog -sn --no-merges v1.0.0..v1.1.0, 17 people contributed to this v1.1.0 release: Jorge Vicente Cantero, Martin Duhem, Tim Nieradzik, Daniel Silva, Paweł Bartkiewicz, Daniel Vigovszky, Josep Prat, Etienne Couritas, Jens Grassel, Martin Mauch, Qi Wang, Ashwin Raja, David Francoeur, Kevin Rauscher, Octavian Genes, Reto Habluetzel, fanconepl, ioleo.
git shortlog -sn --no-merges v1.0.0..v1.1.0
The core team is grateful to all the contributors that have submitted PRs and helped improved the documentation of Bloop. Thanks a lot!
bloopoid released this
Jul 18, 2018
· 2 commits to master since this release
$ curl -L https://github.com/scalacenter/bloop/releases/download/v1.0.0/install.py | python
Initially as an idea by Martin Duhem, Bloop has iterated into its design several times and materialized into a stable compile/test server that people from different build tools can leverage to have a faster developer workflow.
We're in debt with the people that have believed in the project, adopted Bloop and joined our developer team in the early days, most notably @tues, @fizzy33, @rberenguel, @propensive, @lefou and @tindzk.
Bloop v1.0.0 is just the beginning. The next v1.1.0 release will keep focusing on developer productivity and feature more speedups in compilation. Stay tuned.
The configuration file format is a JSON file that describes the configuration of your project. It contains a subset of all the configuration keys required to compile, test and run your project like the project name, source directories, classpath and the like.
Bloop configuration files are easy to generate, easy to read and easy to modify. Bloop keeps a strict forward and backward compatibility on the source files in every major version so that whatever tooling that you build on top of them keeps running in your computers.
After you have exported your build to Bloop configuration files, Bloop can compile, test and run your projects quicker than any other build tool. Bloop can compile your projects around 20-30% faster than sbt.
There are plugin integrations for sbt, Maven and mill that generate configuration files when the task bloopInstall is executed. These integrations allow you to use Bloop for these build tools.
A gradle plugin integration is coming and will be merged into 1.1.0.
Run your Scala Native and Scala.js projects with Bloop. If your build tool supports Scala Native and Scala.js (like sbt), Bloop's integration will automatically create projects for your Scala Native and Scala.js projects. Support for tests and incremental linking is left as future work for 1.1.0.
The Homebrew formulas now installs plist services that will log stdout and stderr to Bloop's log directories /var/log/bloop.
Running Bloop projects in JDK 10 didn't work because NuProcess failed to link with the new process API in JDK 10. Upgrading to the last NuProcess version fixes this issue.
The flag --isolated has been removed because it was not a good default. In most of the cases, users want to clean and test a project in isolation, and propagate that to all their dependencies only in concrete cases.
As a result, a new flag --include-dependencies (aliased to --propagate) has been added to the CLI test and clean commands.
Remove the --parallelism alias of --threads to avoid confusion with the future parallel compilation configuration settings that will be merged in 1.1.0. Use --threads instead.
v1.0.0 is a release that contains changes that span almost half a year. To fully catch up with all the changes that have gone into the creation of v1.0.0, we redirect users to the release notes of all our previous versions.
According to git shortlog -sn --no-merges v1.0.0-M11..1.0.0-RC1, 27 people contributed to this v1.0.0 release: Jorge Vicente Cantero, Martin Duhem, Paweł Bartkiewicz, Ruben Berenguel Montoro, Tim Nieradzik, msvaljek, Jon Pretty, Jorge, Andrew Valencik, Gabriele Petronella, Olivier Mélois, Sam Halliday, David Barri, Alexander Samsig, travisltq, Alexey Alekhin, Emilien Taque, Eugene Platonov, Guillaume Massé, Justin Kaeser, Olivier Melois, Pawel Bartkiewicz, Samantha Li, Sean Sullivan, Stephen Nancekivell, Tobias Roeser and shamsak58.
git shortlog -sn --no-merges v1.0.0-M11..1.0.0-RC1
The core team is grateful to all the contributors that have submitted PRs and helped improved the documentation of Bloop. To a faster developer workflow!
bloopoid released this
Jul 6, 2018
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-RC1/install.py | python
Read the complete instructions in our Installation page.
Check the finished configuration file format JSON Schema here.
The configuration file format is now considered frozen. All the release candidates will work with the new configuration file format, meaning that upgrades to 1.0.0-RC2 will not require a re-generation of the configuration file format.
After 1.0.0, it will be our focus to make forward and backwards source compatible changes in the configuration file format so that users can painlessly upgrade to newer versions of Bloop without:
Any change to the configuration file format that breaks these invariants will go into a 2.x release.
You can now set the default main class for Scala.js or Scala Native projects in the configuration file format.
Disable colors in your logs by using the --no-color CLI flag or exporting the NO_COLOR environment variable. @shamsak58 was also one of our contributors in the Scala Center spree.
Replace -o by -O as the default shorthand syntax for --optimize because the uppercase O is traditionally used to mean optimization in a large array of tools (for example, Clang or gcc).
The latest nailgun version includes Pawel's change to flush output coming from the server ealier than before. This is important so that scripts that use pipes can see the data as soon as possible.
David has kindly updated our systemd instructions with a few improvements to make sure that the services are always up-to-date with the latest Bloop systemd services.
Samantha is a contributor that attended our Scala Center spree in New York. Samantha contributed a fix to the test reporter because the reporter was not correctly printing the total number of executed tests.
The Maven plugin for Bloop now uses Scala 2.10 to avoid a conflict with the Scala 2.10 jars coming from the scala-maven-plugin dependency.
According to git shortlog -sn --no-merges v1.0.0-M11..1.0.0-RC1, 8 people contributed to this release: Jorge Vicente Cantero, Tim NIeradzik, David Barri, Eugene Platonov, Martin Duhem, Samantha Li, Sean Sullivan and shamsak58.
Thank you to the community behind Bloop
Duhemm released this
Jun 16, 2018
$ curl -L https://github.com/scalacenter/bloop/releases/download/v1.0.0-M11/install.py | python
With Bloop 1.0 being around the corner, we need to fix all the issues with the current configuration file format, and come up with a solution that will be stable for a long time.
Jorge has been working towards a definitive design for what the configuration file should look like, and his intensive head scratching resulted in this pull request.
Bloop now includes a Mill integration, which means that your build definition can be exported from Mill's format to Bloop's.
To try the Mill integration, add the following to the build.sc of a project:
And then run mill bloop.integrations.mill.Bloop/install from the directory of the mill project.
This release of Bloop includes support for both Scala.js and Scala Native, contributed by Tim Nieradzik, Jorge Vicente Cantero and Martin Duhem.
Using Scala Native or Scala.js with Bloop is completely transparent. If your project uses any of these platforms, Bloop will automatically configure itself to link and run using the appropriate tools and runtime.
At the moment, running the test is not supported and waiting for [a new release of Scala Native][native-pr-1234].
When sbt is launched with the sbt-bloop plugin, it will now immediately export Bloop configuration files for the build and meta build. This allows a BSP server to directly pick up the changes and notify its client that a build has changed.
This enhancement is crucial for BSP and integration with clients, and improves that overall user experience.
The Bloop configuration file now contains paths to the documentation and sources of the dependencies of a build. This allows a BSP client to query them from Bloop, and lets IDEs offer a better user experience.
Bloop now prints a full report of test execution after the command test finishes. This gives you information about the tests that ran, the failures, errors and successes.
Also, Bloop now correctly reports the outcome of your tests in its exit code.
All the flags that Bloop accepts on its command line interface should be written using kebab-case. Unfortunately, a bug in our autocompletions made Bloop provide suggestions that were using camelCase instead.
Bloop supports an option called --config-dir, which defines where Bloop should look for your configuration files (the default value is .bloop in your current working directory).
When this option was passed, Bloop was creating an absolute path from the base directory where the Bloop server had been started, instead of doing so from your current working directory. This patch fixes this incorrect behavior!
Bloop features a nice error reporter that tries to unclutter your screen and make the most useful bits pop out of your screen. Unfortunately, our reporter was unfriendly to some terminals, and broke links from error messages to source. Thankfully, @gabro fixed that!
The location where the state of the incremental compiler should be stored can now be configured.
Our plugin for sbt used to export only the Compile and Test configurations. @tues improved it so that builds can configure which configuration should be exported, and have Bloop configuration files generated.
Our Maven integration used to have issues with Java-only projects. Thanks to this fix by @lefou, those are now correctly supported by Bloop!
Our developer documentation was still missing information on how to debug Bloop. @tues has been contributing the missing bits!
With the recent improvements to our sbt integrations, our documentation still needed to catch up. The documentation has been updated to reflect the latest additions and capabilities of the sbt integration, and how to configure it properly.
Errors easily get into documentation... Thankfully, our community is here to help. Thank you all for fixing our mistakes:
Even though our Maven integration has been around for a long time, we still hadn't updated our documentation to tell our users how to use it. The documentation is now up-to-date!
The installation script allows to specify the version of coursier that should be used during installation. However, the documentation wasn't mentioning it.
nuProcess is the library that we use to spawn processes. Jorge worked on migrating to the latest version of nuProcess, which includes fixes for bugs that affected Bloop.
Using [scalac-profiling][scalac-profiling], Jorge has been able to determine how to dramatically improve compilation time of Bloop itself. Thanks to his modifications, Bloop can now be compiled much faster!
There were some warnings in our codebase. No more! Enjoy a quiet compilation.
According to git shortlog -sn --no-merges v1.0.0-M10..1.0.0-M11, 11 people contributed to this release: Jorge Vicente Cantero, Martin Duhem, Paweł Bartkiewicz, Tim Nieradzik, Marko Svaljek, Gabriele Petronella, Olivier Mélois, travisltq, Stephen Nancekivell, Tobias Roeser, Alexander Samsig
git shortlog -sn --no-merges v1.0.0-M10..1.0.0-M11
Thank you all
jvican released this
May 16, 2018
· 8 commits to master since this release
$ curl -L https://github.com/scalacenter/bloop/releases/download/v1.0.0-M10/install.py | python
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!
$ 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.