asciidoctor-gradle-plugin provides an extension to define the version of the AsciidoctorJ library to use (https://github.com/asciidoctor/asciidoctor-gradle-plugin#configuration).
This is key to allow users to use new Asciidoctor features without requiring a new plugin release.
Currently this is done in two steps:
- From a custom extension, the dependencies are initialized into a custom configuration (https://github.com/asciidoctor/asciidoctor-gradle-plugin/blob/development/src/main/groovy/org/asciidoctor/gradle/AsciidoctorPlugin.groovy#L55).
- Then, the jars in the configuration are used to initialize a new ClassLoader: https://github.com/asciidoctor/asciidoctor-gradle-plugin/blob/development/src/main/groovy/org/asciidoctor/gradle/AsciidoctorTask.groovy#L843.
Recently we have seen that this causes issues when executed in the Gradle Daemon (https://github.com/asciidoctor/asciidoctor-gradle-plugin/issues/203), because old class definitions are kept in the heap so static attributes are not guaranteed to belong to the same class.
Summing up, my question is: ‘does gradle provide a way to load libraries without playing with a classloader?’.
Reading this about defaultDependencies https://docs.gradle.org/2.5/release-notes#simpler-default-dependencies, it seems to me that the aim of that method is precisely to support what the plugin does, but no logic to load the jars is provided, or I am missing something.