Allow asciidoctor version to be configurable

[aalmiray]

So far every release is tied to an specific version of asciidoctorj. It would be great if the plugin allowed for custom versions to be used (such as snapshots and previews). @melix has suggested we look at https://github.com/melix/jmh-gradle-plugin/blob/master/src/main/groovy/me/champeau/gradle/JMHPlugin.groovy

[mojavelinux]

:+1: Naturally, we'll need to advise that other versions aren't guaranteed to work, but we should aim to maintain compatibility within reason. (I'm not a fan of indefinite backward compatibility).

[aalmiray]

One problem I see here is that the AsciidoctorTask currently relies on loading the Asciidoctor class directly from the classpath. Enabling a custom configuration might force us to use reflection to locate the Asciidoctor class and instantiate it; but it's doable.

The jmh plugin does not suffer from this because it invokes JMH via JavaExec.

[ysb33r]

Thinking about this in reverse, starting at the gradle plugin....

dependencies {
  // Set the version explicitly, if not set defaults to whatever is set within the asciidoctor gradle plugin
  asciidoctor 'org.asciidoctor:asciidoctor-java-integration:1.5.1'
}

This will probably run into the problem that @aalmiray mentions, but I think it is workable. However this is just the start of the current dependency dilemma.

What about the dependency between asciidoctorj and asciidoctor? Unless there a specific API changes in asciidoctor gem that asciidoctorj needs, should the latter be hard linked to a specific version of the former? Probably a can of worms being opened here, especially if we are inside a gradle plugin, how would it then know how to pull rubygems?

That sticky toffee aside, we are left with one more dependency problem to solve - that of adding backends. For instance if I want to use deckjs or revealjs, I have to git submodule (or import) two repositories into my document tree. From a gradle user point of view, this can be a barrier to entry. It would be nice if seomthing like the following can work:

// Adding dependency ...
dependencies {
  asciidoctor 'org.asciidoctor:deckjs-gradle-plugin:[1.1,1.3]'
}

// will allow classpath to be searched for additional backend
asciidoctor {
  backends ['deckjs']
}

Obviously @mojavelinux has a point about backward compability. Consumers are on their own, if they go outside of the boundaries of known compatible versions, but giving the flexibility of being able to do it, makes field testing of new features by consumers a lot easier.

[mojavelinux]

:+1: