# \[ANN\] Kroki.jl v0.2.0

**URL:** <https://discourse.julialang.org/t/ann-kroki-jl-v0-2-0/84822>\
**Category:** Package Announcements\
**Created:** [July 26, 2022, 12:37pm UTC](https://discourse.julialang.org/t/ann-kroki-jl-v0-2-0/84822 "2022-07-26T12:37:02Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![bauglir](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/bauglir/32/31897_2.png) [@bauglir](https://discourse.julialang.org/u/bauglir)\
**Post date:** [July 26, 2022, 12:37pm UTC](https://discourse.julialang.org/t/ann-kroki-jl-v0-2-0/84822/1 "2022-07-26T12:37:02Z")

</div>

Just in time to celebrate the second anniversary of its first public appearance at [JuliaCon 2020’s poster session](https://live.juliacon.org/uploads/posters/M8KTBL.pdf), I’m pleased to announce the [v0.2.0 release of Kroki.jl](https://github.com/bauglir/Kroki.jl/releases/tag/v0.2.0).

A quick refresher: Kroki.jl is a package that enables a variety of (textual) diagramming tools within Julia, e.g. [PlantUML](https://plantuml.com), [Mermaid](https://mermaid-js.github.io), etc. through the [Kroki service](https://kroki.io). An overview of all supported types of diagrams is available in [the documentation](https://bauglir.github.io/Kroki.jl/v0.2.0/#diagram-support).

This release contains many improvements including:

- An extended, and `export`ed, 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](https://bauglir.github.io/Kroki.jl/v0.2.0/examples).
- New diagram types, e.g. [BPMN](https://bpmn.io/), [Byte Field](https://bytefield-svg.deepsymmetry.org/bytefield-svg/1.6.1/intro.html), [Structurizr](https://structurizr.com), [Excalidraw](https://excalidraw.com) and more.
- Support for [loading diagram definitions from file](https://bauglir.github.io/Kroki.jl/v0.2.0/examples/#Loading-from-a-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](https://bauglir.github.io/Kroki.jl/v0.2.0/examples/#Diagram-options). Useful for Structurizr diagrams containing multiple views, or to manage themes for PlantUML diagrams.
- Kroki [service management](https://bauglir.github.io/Kroki.jl/v0.2.0/api/#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](https://github.com/bauglir/Kroki.jl/blob/v0.2.0/CHANGELOG.md#020-2022-07-26).

---

<div class="post-metadata">

**Author:** ![jling](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jling/32/212909_2.png) [@jling](https://discourse.julialang.org/u/jling)\
**Post date:** [July 26, 2022, 12:40pm UTC](https://discourse.julialang.org/t/ann-kroki-jl-v0-2-0/84822/2 "2022-07-26T12:40:34Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![bauglir](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/bauglir/32/31897_2.png) [@bauglir](https://discourse.julialang.org/u/bauglir)\
**Post date:** [July 26, 2022, 1:13pm UTC](https://discourse.julialang.org/t/ann-kroki-jl-v0-2-0/84822/3 "2022-07-26T13:13:18Z")

</div>

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 😅