The goal of AsciidoctorJ is to open up Asciidoctor the Java ecosystem. The current interface in AsciidoctorJ uses JRuby as the bridge. JavaScript integration is also in the works using Nashorn or similar. In most cases, I think these integration options work great. It may be worth exploring other approaches, as Alex points out in this comment on an Arquillian Recorder issue:
Nowadays we have two problems for doing this, the first one is that
Asciidoctor is written in Ruby so you require that users have installed
Ruby which IMO is a problem for people who don't use Ruby. The second
problem is ok, let's use AsciidoctorJ. It could be a good approach but
AsciidoctorJ depends on JRuby which its size is 20MB, so although we don't
need arquillian-spacelift at all, Maven will need to download a dependency
of 20MB, so you may find that this is a problem. The problem of size will
be issued in next versions of AsciidoctorJ (splitting JRuby or using
Javascript as engine instead of JRuby but this will be in future not now :()
When I was reviewing the Grain framework, I noticed they are using a dispatcher pattern to invoke a Ruby library such as Asciidoctor. We could formalize this into a separate AsciidoctorJ interface that can detect which bridge to take to Asciidoctor, or allow the bridge to selected explicitly. Perhaps call it something like asciidoctorj-dispatcher.
Here's the dispatcher "RPC" code at the core of the Grain framework.
Here's how it gets invoked:
*If* we decide we need to support alternative ways to invoke Ruby code, then I think this would be worth exploring.
NOTE: I like the word "bridge" better than "RPC" since not all the implementations are remote calls.
This is just something to think about it. It may or may not be urgent, but certainly something to keep in the pipeline.
-Dan
--
Locked
