asciidoctor-gradle-plugin
asciidoctor-gradle-plugin copied to clipboard
asciidoctor
Make asciidoctor plugins work with Gradle's configuration cache
Gradle 6.6 introduces the configuration cache that allows Gradle to save a task graph and reusing it when nothing influencing it has changed. In other words, to skip the configuration phase altogether.
See https://docs.gradle.org/current/userguide/configuration_cache.html and https://blog.gradle.org/introducing-configuration-caching
Making the asciidoctor Gradle plugin suite compatible with the configuration cache would help users by allowing them to enable it and skip the configuration phase in their development/authoring feedback loop.
Using the asciidoctor jvm plugin currently fails with problems reported up to the base tasks so all plugins should be affected.
Here's a sample HTML report produced by gradle when running with --configuration-cache:
configuration-cache-report.html.zip
#558 was an attempt at making some progress on this but as commented there I think the current PR should be dropped.
Here's a copy of my notes on this PR:
I took a look at what it would take to make this plugin work with the configuration cache and the main issue is with accessing the project at execution time. It's done all over the place.
Many cases can simply be fixed by using injected services instead, working with files, executing java programs etc... Those would require compiling the plugin with Gradle 6 but are pretty simple to fix.
BUT, a lot of the tasks gather their configuration at runtime from task and project extensions using some helpers from the grolifant project. This not only makes it hard to detangle from the project because of the required dance between the two projects to fix things, but it's also a sign that the tasks do too much of configuration. If the plugin was responsible for wiring all the task inputs instead then things would be simpler, most probably with more complex inputs though.
Finally there's the usage of detached configurations created at runtime, dependency instances created at runtime etc... This simply can't be done with the configuration cache enabled. It could be modelled differently as proper input properties but it will require some work.
4.0.0-alpha.1 is out. Now you can start doing real testing against the configuration cache. (I suspect some of the issues you find might need to be rolled upstream to Grolifant).
4.0.0-alpha.1 doesn't help much. The asciidoctor tasks still hold references to disallowed objects.
See the attached CC report: configuration-cache-report.zip
Please reopen the issue.
Correct 4.0.0-alpha.1 is just the start. There is for sure a bunch of things in the code that references project instances. They can now be tackled on a piece by piece basis. (Would make a lovely GSoC project).
Also the other problem is the current jrubygradle plugins that are in use. These in their current state will never bee CC compatible.
I am however working on a complete replacement.
@ysb33r I also just tried out the configuration cache in the JUnit build and ran into this issue.
This issue is still valid. The configuration cache is marked as stable since Gradle 8.1. Are there any plans to move this forward?
