[ANN] Kroki.jl v0.2.0

Package Announcements
1

Just in time to celebrate the second anniversary of its first public appearance at JuliaCon 2020’s poster session, I’m pleased to announce the v0.2.0 release of Kroki.jl.

A quick refresher: Kroki.jl is a package that enables a variety of (textual) diagramming tools within Julia, e.g. PlantUML, Mermaid, etc. through the Kroki service. An overview of all supported types of diagrams is available in the documentation.

This release contains many improvements including:

  • An extended, and exported, public API to officially support more use cases, such as rendering directly to specific output formats.
  • Support for interpolation when using string literals to create diagrams.
  • Improved documentation, including examples.
  • New diagram types, e.g. BPMN, Byte Field, Structurizr, Excalidraw and more.
  • Support for loading diagram definitions from file. Useful when including diagrams in multiple places across a codebase, or when its easier to maintain the diagrams themselves using other tools.
  • Support for diagram options. Useful for Structurizr diagrams containing multiple views, or to manage themes for PlantUML diagrams.
  • Kroki service management to switch between different service hosts, manage a local instance (useful when rendering proprietary diagrams), and retrieve version information.

For full details see the CHANGELOG.

12 Likes
2

I was gonna say it would be nice to ship Kroki in a _jll by default instead of pinning some remote server by default, then I checked the installation guide:

You’ve installed Java 8 on your Linux machine.

3

I go back and forth on this a bit. I think there is definitely a use case for having _jll versions of most of these tools, as you don’t always want to, or even can, rely on an external service. But as you already mention that quickly gets you into having to install Java and such and that’s where I tend to draw the line as well. I tried doing that for PlantUML a couple of years ago prior to starting this package and abandoned that pretty quickly. At the time it was too much work to make it worth the effort at least.

I find being able to rely on Kroki to wrap these tools behind a consistent API is a nice low-barrier to entry to starting to use these types of tools. Plus it makes this package a lot easier to maintain :sweat_smile:

1 Like