search

asciidoctor / asciidoctor-diagram

:left_right_arrow: Asciidoctor diagram extension, with support for AsciiToSVG, BlockDiag (BlockDiag, SeqDiag, ActDiag, NwDiag), Ditaa, Erd, GraphViz, Mermaid, Msc, PlantUML, Shaape, SvgBob, Syntrax, UMLet, Vega, Vega-Lite and WaveDrom.
http://asciidoctor.org
MIT License
431 stars 106 forks source link

Use graphviz-java for rendering graphviz #376

Open StefanHirche opened 2 years ago

StefanHirche commented 2 years ago

Hi, would it be possible to use the graphviz-java jar to render all graphviz diagrams instead of calling the binary? The lib is provided here: https://github.com/nidi3/graphviz-java

pepijnve commented 2 years ago

It's definitely feasible, but not something I'm planning on working on anytime soon. PRs are welcome of course.

ManDay commented 9 months ago

Why do you want that? I would rather hope that asciidoctor-diagram (AD) takes the opposite approach, where different softwares are supported plug-and-play, rather than being hard-built into AD. Doing that seems to be the entirely wrong approach, as AD grows into a large, difficult-to-maintain monolithic structure.

Either one of the following two approaches seems better to me:

  1. Split AD into one extension per backend, thus becoming asciidoctor-gnuplot, asciidoctor-graphviz, etc. This is probably the best and most conformant solution which will satisfy everyone equally.
  2. Support all backends in a single AD, as it currently is, but do so flexibly, depending on which of the backends is installed on the user's system. AD would, generically, only serve as a passthrough to different marshalling plugins (gnuplot, graphviz, ...) which then pass the stream to their according binary and retrieve the result in the correct fashion.

Eventually, the 2nd approach also naturally leads back to the 1st, as the mere passthrough is barely worth the unflexibility of combining them all into a single package.

I'm currently not using AD, very much because it's a large chunk of stuff, including a dependency on Java, of which I barely want or need one or two backends.

pepijnve commented 9 months ago

I'm not sure what you're complaining about @ManDay. What you're asking for is pretty much the way things are already.

The extensions are all packaged in one big gem, but each of the formats is a distinct extension that you can choose to require or not as you prefer. If you require asciidoctor-diagram you're going to get everything, because that's what you're asking for. If you just want graphviz for instance, require asciidoctor-diagram/graphviz instead. I experimented with multiple gems at one point, but it was more hassle than it was worth.

There's no hard dependency on Java, except when you actually use a Java based rendering tool like PlantUML. That's unavoidable. PlantUML was originally embedded in the main gem. It was moved to a separate gem quite some time ago. That gem exists purely as a convenience to users. It's still listed as a runtime requirement mainly for backwards compatibility reasons. Severing that link risks breaking existing deployments. I value not breaking user setups over some theoretically ideal structure.

The gem was larger than necessary due to a silly packaging mistake on my part. The 2.2.12 build is around 85Kb. If that's still too large for you, you're welcome to use some other library.

ManDay commented 9 months ago

Lets consider the two issues (and I apologize for mixing this into one thread):

  1. The original comment asks to replace the IPC to graphviz by using a Java interface. I hope you can agree that this dependency on the entirety of Java, being not the most popular language, for something which can be done as simply as by piping to a binary is more than just "some theoretical ideal structure". Even for someone who is not as concerned with pruning dependencies as I.
  2. Concerning the current structure and the existing dependency on Java, how do you suggest asciidoctor-diagram be packaged by downstream for distribution? They can't skip the dependency on Java, or any other thing which compiles. At least Gentoo (which I use) can't. Not without patching it downstream.
pepijnve commented 9 months ago

  1. Is not about replacing it. It's about optionally using the pure Java implementation instead of the original C implementation. I'm not planning on implementing that, but I can understand why someone could want that functionality.

  2. I don't agree that downstreams have to have a hard requirement on Java just because there's an optional codepath in the gem that uses it if it's available. If downstreams want a simple installation solution they can make an empty package per diagram type that depends on the core one and all the required tools for that diagram type. Or declare everything optional and let users install the required packages themselves. Either way, I'm not planning on changing the way this gem is distributed.