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
436 stars 106 forks source link

Sources of the *.jar files #314

Closed eclipseo closed 3 years ago

eclipseo commented 3 years ago

In order to be integrated into Fedora, the jar files must be compiled from source, as precompiled binaries is a no-no. It is unclear as to where upstream is located for some of them, would you be kind enough to provides upstream/repo/build instructions for them in order to have reproducible builds?

pepijnve commented 3 years ago

The glue code can be found at https://github.com/asciidoctor/asciidoctor-diagram-java

The Ditaa fork is from https://github.com/pepijnve/ditaa. Ditaa development seems to have stalled. I created that fork to fix some bugs and strip out unused code and features.

The PlantUML jar is the unmodified Apache licensed variant downloaded from https://plantuml.com

snecklifter commented 3 years ago

@pepijnve thanks for the info, can I just check on upstream for jlatexmath-minimal pls?

pepijnve commented 3 years ago

That's actually a PlantUML dependency. See the bottom of the page at https://plantuml.com/ascii-math

snecklifter commented 3 years ago

@pepijnve thanks but after jlatexmath 1.0.4 there was a switch to maven builds and the -minimal option appears to have been dropped, so I'm still not clear on where the 1.0.5 version comes from that asciidoctor-diagram ships with or how to construct it?

pepijnve commented 3 years ago

Neither am I to be honest. I think I just downloaded it via the PlantUML site.

snecklifter commented 3 years ago

@pepijnve the minimal jar is no longer being produced as per response from a maintainer in the above issue. It looks like from #312 I can use system-provided JARs however?

pepijnve commented 3 years ago

I don't think I made a release with that environment variable based loading strategy already. Allowing users to use their own version of PlantUML is indeed the direction I want to take. I wasn't sure yet what the most appropriate way to configure this would be. Env var, confit file, ...

Longer term I'm thinking of not even including the PlantUML jar in the gem at all, but that'll be something for a 3.x release since it's a breaking change for most users.

snecklifter commented 3 years ago

@pepijnve yes, would be good not to carry the jars I think. Its certainly making it more problematic to ship in Fedora.

In terms of the best way, I think a config file would be preferable to setting environmental variables as its probably going to be a system-wide setting so should affect all users. WDYT?

anderscore-hjhessmann commented 3 years ago

The jlatexmath is an optional dependency of PlantUML. It's required for math expressions. For details see PlantUML Math.

In my opinion an environment variable is a good solution. One might want to use different versions of PlantUML. But there should be some easy to use default.

Currently I simply replaced the plantuml.jar within the gem directory. This worked for me.

By the way. Maven and Gradle both support ruby-gems. Isn't there a similar solution for gem that supports java-repositories like maven central?

pepijnve commented 3 years ago

But there should be some easy to use default.

I'm working on something to allow a smooth transition from the embedded jar to a bring-your-own-jar model. Doing that in a way that does not break backwards compatibility is the tricky part.

By the way. Maven and Gradle both support ruby-gems. Isn't there a similar solution for gem that supports java-repositories like maven central?

Not that I know of.

pepijnve commented 3 years ago

I've updated PlantUML, Batik and JLatexMath to their respective most recent stable revisions and bundled them up in a separate gem (https://rubygems.org/gems/asciidoctor-diagram-plantuml).