I've been working in making the Gradle build for a OSS project fully cacheable. We've discovered that sometimes, when killing the Gradle daemon and running a new one (I think, not 100% sure, it might also be dependent on the absolute path of the project in my machine), the runtime classpath for the Asciidoctor tasks changes the order of the Groovy JARs taken from the GRADLE_USER_HOME. This causes the task to miss the build cache and render the documentation all over again.
Example:
Having a look at the sources, and the help of coworkers wiser than me, I think the problem is in here:
But it's probably not a LinkedHashSet, so the ordering of the elements when adding new ones in line 628 is not guaranteed. I think having a SortedSet, for example, would fix this problem.
I've been working in making the Gradle build for a OSS project fully cacheable. We've discovered that sometimes, when killing the Gradle daemon and running a new one (I think, not 100% sure, it might also be dependent on the absolute path of the project in my machine), the runtime classpath for the Asciidoctor tasks changes the order of the Groovy JARs taken from the GRADLE_USER_HOME. This causes the task to miss the build cache and render the documentation all over again.
Example:
Having a look at the sources, and the help of coworkers wiser than me, I think the problem is in here:
https://github.com/asciidoctor/asciidoctor-gradle-plugin/blob/996df6a028b69e3f7314ed61ca6af317776ace74/jvm/src/main/groovy/org/asciidoctor/gradle/jvm/AbstractAsciidoctorTask.groovy#L628
We are adding dependencies from the local Groovy to a Set that's already been created from a Stream:
https://github.com/asciidoctor/asciidoctor-gradle-plugin/blob/996df6a028b69e3f7314ed61ca6af317776ace74/jvm/src/main/groovy/org/asciidoctor/gradle/jvm/AbstractAsciidoctorTask.groovy#L621
But it's probably not a LinkedHashSet, so the ordering of the elements when adding new ones in line 628 is not guaranteed. I think having a SortedSet, for example, would fix this problem.