wisdom-asciidoc-maven-plugin has no support for asciidoct-diagram

[Riduidel]

I would like to add plantuml diagrams in my asciidoc, bu it doesn't work with wisdom-asciidoc-maven-plugin.

Mimicking the asciidoctor-maven-plugin, I tried to add the asciidoctorj-diagram dependency, but it changed nothing.

So ...
Should I rewrite the wisdom-asciidoc-maven-plugin ?
Should I create a wisdom-asciidotorc-maven-plugin ?
What is the best way to integrate diagrams in asciidoc generated by Wisdom ?

[cescoffier]

Did you try to update the "asciidoctor" version and then add the dependency ?

I never tried to integrate plantuml, but I agree it's pretty cool !

[Riduidel]

No, i didn't tried that, but I think there is another way to do it.
If I understand correctly, the wisdom-asciidoc-maven-plugin directly fires the asciidoc system when a modification is detected.

There is a library, called Mojo Executor which allow one to call another plugin with configuration injected from Java code. using that library, it would be easy to have maven-asciidoc-plugin invoke the version of the asciidoctor-maven-plugin with the right set of options, and the right classpath.

What do you think ? Would it be a nice evolution of that plugin ?

[cescoffier]

MojoExecutor is nice but bring some classloading issue….

…

On 20 Jan 2017, at 15:32, Nicolas Delsaux ***@***.***> wrote: No, i didn't tried that, but I think there is another way to do it. If I understand correctly, the wisdom-asciidoc-maven-plugin directly fires the asciidoc system when a modification is detected. <https://camo.githubusercontent.com/592b632e32dd2803ddcfcef587360598cfbe1f18/68747470733a2f2f63646e2e6d656d652e616d2f63616368652f696e7374616e6365732f666f6c6465723239352f353030782f37343838323239352e6a7067> There is a library, called Mojo Executor <http://timmoore.github.io/mojo-executor/> which allow one to call another plugin with configuration injected from Java code. using that library, it would be easy to have maven-asciidoc-plugin invoke the version of the asciidoctor-maven-plugin with the right set of options, and the right classpath. What do you think ? Would it be a nice evolution of that plugin ? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#566 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAYjfam5Wwh_Z43ZlwJXBAWzsSG4e1a7ks5rUMVxgaJpZM4LpKwa>.

[Riduidel]

Well, in fact, I have two options :

1. use Mojo-Executor down the rabbit hole (dunno why you talk about Classloader issue : the other plugin has to be in MojoExecutor classpath, which means in plugin dependencies)
2. Directly extend the AsciidoctorMojo. I'm less fond of this approach, for ideological reasons (composition over inheritance, blablabla)

Which one do you prefer ?

[cescoffier]

I would go for the Mojo-Executor and see how it goes.

…

On 20 Jan 2017, at 15:52, Nicolas Delsaux ***@***.***> wrote: Well, in fact, I have two options : use Mojo-Executor down the rabbit hole (dunno why you talk about Classloader issue : the other plugin has to be in MojoExecutor classpath, which means in plugin dependencies) Directly extend the AsciidoctorMojo. I'm less fond of this approach, for ideological reasons (composition over inheritance, blablabla) Which one do you prefer ? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#566 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAYjfRrE3gylKICn9bO-tMxrYS7_-ct-ks5rUMpIgaJpZM4LpKwa>.

[Riduidel]

OK, I think I've tried to stretch my classloader-fu too much and got kicked in the balls.
As a consequence, I will downgrade my objective and just make sure our invocation of asciidoctor is clean enough to allow additional CLASSPATH to be used (and as a consequence allow asciidoctor-diagram to work, which was my initial goal).