I couldn't really help myself. After coming up with a plan to restructure and stabilise Bascule, I went off-piste and split the project in two and started work on PDF generation.
I want to make Bascule extendable, and to do that I've created an API and core model project bascule-lib. It defines a couple of interfaces and the object model classes (Post, Project, Tag, PostLink). It also includes a sample implementation of a PDF generator class SinglePagePDFGenerator which builds a document containing every post on the website. It doesn't work very well, for lots of reasons, but it's a start.
It has been useful, though, as it reveals some weaknesses and challenges that Bascule will have to face in the future. For instance, the project model class is a pretty confused and constructing it is split between Bascule and bascule-lib. As the project configuration gets more complicated, the current approach is going to be unsustainable.
Introducing Coroutines
The Kotlin programming language team seem very proud of their concurrent programming approach called coroutines. It promises a lightweight approach to concurrency and parallelism, without the overhead of the Java thread model. There are a few steps in Bascule generation which can, in theory, be run in parallel, so I've been experimenting with adding this feature. Specifically, once all the source Markdown files have been parsed and generated as HTML, the other pages - the home page, the taxonomy tag list pages, and the complete navigation lists - can all be generated independently of each other. Most of these operations are IO-heavy, so performance improvements are likely to be minimal. Still, it seems to work for now and I suspect the benefits will be more evident as the number of source files increases.