|Re: [asciidoc-wg] AsciiDoc implementation for the Java/JVM ecosystem / project proposal|
Hello Dirk, On 13.06.2020 20:20, Dirk Detering wrote:
The reason to supply a native JVM based asciidoc implementation is in my eyes to give Java developers the full power to create tools and plugins and orchestrate their toolchain in their native environment, without having to jump into a different language system. To explain that from a practical point of view: As Java developers, trying to find an easily manageable way to maintain developer manuals and architecture doc, the Asciidoc Maven plugin and asciidoc-pdf were straightforward, while integrating even the Docbook toolchain was too much of a burden. Only that we now brought Ruby somewhere into the formula felt not quite fine, in case we need to open the blackbox.
I understand that a Java developer will lean to a Java implementation when creating a build pipeline the same way a Rust developer will lean to a C/Rust implementation. I consider all implementations part of the AsciiDoc ecosystem. Time will tell if there will be one or more JVM implementation. The new JVM implementation will aim to provide HTML output first. Reading the other discussions there are good arguments to provide a HTML output that is the same for all implementations. To my experience PDF output depends on the library being used. An output that look identical for all implementations is out of reach IMHO. And also quite far in the future, as it will come after a stable HTML output. Best regards, Alexander Alexander Schwartz (alexander.schwartz@xxxxxxx) https://www.ahus1.de
Back to the top