Up-to-date check miss when unspecified file is changed

[mojavelinux]

If a file is changed that resides within the sourceDir, but that file is not specified in either the sources or resources, Gradle runs the asciidoctor task again (meaning the up-to-date check fails).

This extra (and unnecessary) work becomes especially noticeable when using continuous build mode, particularly since the asciidoctor task takes a lot longer than other tasks to run.

I'm not sure if this is a problem in the plugin or simply a limitation of Gradle.

I'll give an example of when this comes up. Let's assume I have the following files in my project, a typical structure for a Bespoke.js presentation project:

build.gradle
src/
  index.adoc
  images/
    html5.svg
  scripts/
    main.js

And I've configured the Asciidoctor plugin as follows:

asciidoctor {
  sourceDir 'src'
  sources {
    include 'index.adoc'
  }
}

If I modify src/scripts/main.js, the asciidoctor task runs again, even though the AsciiDoc file has not changed.

The solution to this problem seems to be move to a split hierarchy. Any files that should not cause the asciidoctor task to fire need to be moved out of the directory specified in the sourceDir. In other words, something like:

build.gradle
  src/
    content/
      index.adoc
      images/
        html5.svg
    app/
      scripts/
        main.js

and

asciidoctor {
  sourceDir 'src/content'
  sources {
    include 'index.adoc'
  }
}

[ysb33r]

This has been addressed for 2.0.x via the additionalSources block.

[ysb33r]

In 2.0 you will need to specify any such files via

asciidoctor {
    secondarySouces {
      include '**/arbitrary.file'
   }
}

This tells Asciidoctor to look for files that might change, but which are nto actual source files that will be processed. This approach makes the intent clear and more descriptive than use of a generic inputs.files appraoch. It also fits with other task approaches in that rebuilds only occur for specific patterns.

As an additional win to the mentioned secondarySources approach, a task type may add it's own patterns to seocndary sources. For instance when the backend is html5, the secondary sources will include *docinfo*.html files and when the backend is docbook, *docinfo*.xml file patterns are added. The asciidoctorPdf tasks adds *-theme.ym*l.

I think this is adequately covered, so I am closing this issue. Feedback on 2.0-alpha.2 will be welcome.