Closed shanemikel closed 2 years ago
Can you confirm the version for the maven plugin? In theory latest asciidoctor-maven-plugin v2.2.2 uses Asciidoctorj 2.5.3 which uses jcommander v1.81.
I was just following the instructions from asciidoctor.org to add the asciidoctorj
dependency v2.5.2 in maven:
<dependencies>
<dependency>
<groupId>org.asciidoctor</groupId>
<artifactId>asciidoctorj</artifactId>
<version>2.5.2</version>
</dependency>
</dependencies>
Looks like asciidoctor.org is behind on the latest release version. Confirmed IntelliJ stops complaining when I change asciidoctorj
to v2.5.3.
Looks like asciidoctor.org is behind on the latest release version.
The docs come from this repository. Here's the source file: https://github.com/asciidoctor/asciidoctorj/blob/main/docs/modules/ROOT/pages/installation.adoc
The versions in the metadata file are behind:
https://github.com/asciidoctor/asciidoctorj/blob/main/docs/antora.yml
Ideally, that file would get updated during the release process. Until then, keeping it in sync requires a manual update.
Docs update a side for a moment.
But I am concerned your project configuration is not 100% right. Nothing serious, worst case scenario your are pulling an extra dependency and building docs with a newer AsciidoctorJ version. By default the maven-plugin only requires the AsciidoctorJ dependency if you want to replace the default one and the docs you link are to use AsciidoctorJ in your project as a library.
Can you confirm which case are you using? Is AsciidoctorJ within the <build><dependencies>
or inside <dependencies>
inside the <plugin>
block?
@abelsromero I managed to get an asciidoctor to html build working with the asciidoctor-maven-plugin. You're right, I didn't need to specify the dependency or version for asciidoctor-maven-plugin anywhere other than <build><plugins>
. I didn't need to refer to asciidoctorj directly at all.
I would like to use asciidoctor-diagram, asciidoctor-pdf (or use docbook and figure out a Java only build system to go from docbook to PDF), and some latex math & mathml extension with asciidoctorj, natively. I'd like to avoid external/environmental dependencies entirely.
My hope was to use end-to-end Java stack so I could version design docs in repos alongside Java code. Collaborators could easily contribute to notes and build with Maven or Ant. If I can't get the whole stack on the JVM I will probably containerize the asciidoc build system and switch to the Ruby implementation.
Looks like even AsciidocFX has an environmental dependency on the graphviz package, but it's not clear from the docs if they are using asciidoctor-diagram or implemented a standalone plantuml extension. They don't mention diagram types from asciidoctor-diagram other than plantuml.
I don't see how to avoid duplicating asciidoctor plugin configuration with Maven. My prototype project currently has profiles for running nearly identical http
and process-asciidoc
goals. One is to be used for easy editing and the other for compiling notes to print or publish, but much of the config should be shared. Maven doesn't allow straightforward reuse of arbitrary XML fragments in the pom.xml. It's not a big deal so far, but I imagine it will get unwieldy once I add other targets like PDF.
Instead of using asciidoctorj-maven-plugin, I would like to specify the asciidoctorj dependency in Maven, and roll my own Ant script for calling the asciidoctorj CLI. The idea is to specify arguments/configuration outside of Maven, like the DITA toolkit shows in the docs to use a project.xml.
I like the flexibility of doing this with Ant, as shown in the DITA-OT docs. Even in the DITA example, though, they rely on an environmental installation of the DITA command. That's a non-starter for me.
The original issue is apparently fixed since AsciidoctorJ has upgraded its dependency on jcommander to 1.81.
For questions about using this or related projects please use the zulip chat at https://asciidoctor.zulipchat.com.
IntelliJ reports a vulnerability when adding AsciidoctorJ v2.5.2 as a Maven dependency: https://advisory.checkmarx.net/advisory/vulnerability/Cx8fd408ac-dd80
jcommander referenced its own dependencies using http instead of https. This was apparently fixed in jcommander v1.78.