Release Summary 📝
Version 0.1.7 features various UI improvements as well as new commands for running, publishing and documenting modules.
You can follow the linked pull requests for detailed descriptions of the changes.
Migration Steps 💻
Use the following command to upgrade Seed:
blp-coursier bootstrap \
-r bintray:tindzk/maven \
tindzk:seed_2.12:0.1.7 \
-f -o seedThe latest stable Bloop version 1.3.2 is recommended. Builds generated by Seed should be compatible with the newer prerelease version 1.4.0-RC1 too.
This release is fully backward-compatible.
New Features 🚀
Project website (#68, #69)
The project documentation is now available as a separate website, courtesy of @hejfelix.
BSP support (#63)
This release integrates more tightly with Bloop. Previously, all Seed commands relied on Bloop CLI invocations which had several limitations (see #63). The majority of these were replaced by BSP requests.
This opened up the ability to make various user-facing improvements outlined in the following subsections.
Progress bars
When building modules, Seed subscribes to BSP notifications. Since Bloop publishes structured information on the compilation process, we can show progress bars in all Seed commands involving compilation. This is particularly useful in modular projects and helps to identify bottlenecks in the build pipeline:
Run command
In addition to the already-existing link and build commands, run was introduced. The new command is similar to bloop run <module> which runs the main class of the supplied module. It is currently limited to only one module since programs may be non-terminating.
Watch mode
Seed can now register file watchers and trigger a new compilation pass whenever source files have changed. The watch mode is compatible with long-running processes such as servers:
Furthermore, the user can run operations in parallel on multiple modules defined in the same build (which solves a limitation in Bloop v1.3.2). As an example, this makes the following workflow for client/server applications possible:
seed link client --watch # Terminal 1: Link Scala.js frontend
seed run server --watch # Terminal 2: Run Scala JVM backendPublishing modules (#77)
With the new CLI command publish, modules can be published to a repository. The command packages and uploads the compiled class files, sources and documentation. At the moment, only Maven-style Bintray repositories are supported.
The following example shows how to publish a project to Bintray:
The first step is to define a [package] section in the build configuration. Afterwards, we set a Git tag for the new release. Finally, running the command seed publish <target> <modules> builds, packages and uploads the supplied module.
For more information, please refer to the sections on credentials, build configuration and usage in the manual.
Documenting modules (#77)
A new CLI command doc is available for generating HTML documentations. doc takes a list of modules and runs Scaladoc on them separately. It supports Scala 2.11, 2.12 and 2.13, including alternative compilers such as Typelevel Scala.
doc can be invoked on any module without any changes to the build file:
Scala.js 1.0 support (#92, #97)
Several changes were made for Scala.js 1.0 compatibility. Whilst Bloop 1.3.2 does not support Scala.js 1.0 yet, Seed builds are compatible with the upcoming Bloop 1.4.0 release.
Once Bloop 1.4.0 has been published, a new Docker image will be made available too.
Bug Fixes 🔥
- Scaffold: Set correct root path when only one platform was selected (#65)
- Scala.js: Compatibility with Bloop 1.4.0+ (#71, #97)
- Bsp: Log correct line and column numbers (#73)
- ArtefactResolution: Fix resolution of test modules (#85)
- BuildConfig: Detect invalid references on platform modules (#86)
- ArtefactResolution: Fix publishing and resolution of Scaladoc bridges (#88)
- Publish: Honour progress bar setting (#89)
- Publish: Use absolute path when determining Git version (#93)
- BuildTarget: Resolve exception when no parent modules available (#95)
- ArtefactResolution: Fix inheritance on test modules (#96)
More robust resolution (#77)
Previously, all dependencies were resolved at once. Modular projects are likely to contain libraries with diverging versions across different modules. A Coursier resolution pass merges these duplicate libraries, only retaining the latest version. This may lead to unexpected compile- and runtime behaviour. The new resolution logic solves this limitation by performing a separate resolution pass for each module. As a consequence of these changes, the resolution will be slightly slower, but the speed is still acceptable on larger projects.