General:
- Use 'base' plugin model for Asciidoctor plugins.
- Only support Gradle 4.0+.
- Only support JDK8+.
- For Gradle 4.5+ migration messages are controlled via `--warning-mode`.
- For Gradle 4.0-4.4 migration messages are controlled via `--info`.
- Additional text will be displayed on Gradle Plugin Portal for during
  alpha & beta releases.
- Compatibility testing has been added and initialy against Gradle
  versions 4.0.2, 4.3.1 & 4.6. (For JDK10 only test against 4.7).
- JDK compatibility testing are done from JDK8 -> JDK10 (Travis)
- Codenarc settings has been updated to find configuration from within
  subprojects.
- Updated license headers to include 2018.
- Integration tests utilises an offline Ivy repository (via Ivypot plugin)
  to reduce bandwith usage and test time.
- AsciidoctorJ, GroovyDSL etc. versions are defined in code and read by the
  build script. This provides one point of definition and ensure that code
  can have appropriate default versions.

New generation plugins and tasks:
- New (JVM) AsciidoctorJ extension can be added to both project & tasks.
  Extension in task can be used to override global settings from the
  project extension. It takes into account some of the ideas @manuelprinz
  had for asciidoctor#231 for is much more extensive.
- Extension has support for Asciidoctor verbose mode (asciidoctor#233).
  If `verboseMode` is set then a temporary file will be created and made
  part of Asciidoctor `requires`.
- JRuby version can be controlled at both project and task level. If no
  version is specified at either level, the default JRuby version that
  AsciidoctorJ depends on will be used.
- GroovyDSL extensions are now registered eitehr on the project extension
  or the task extensions. The extensions are only loaded within a worker
  instance. The asciidoctor task is unloaded at the end of the worker and
  with it the extensions. (asciidoctor#166)
- AsciidoctorTask differentitates between top-level sources, secondary
  sources and resources in order to have a better idea of being
  out-of-date. (asciidoctor#185)
- It is possible to control whether resources should be copied or not. This
  allows a build to better deal with a backend such as PDF, which do not
  need resources to be copied.
- It is possible to perform the conversion from an intermediate working
  directory, which allows for a source directory to be kept pristine from
  intermediate artifacts generated from extensions such as ditaa.
- Using a worker approach for running Asciidoctor instances. (asciidoctor#220)
- Asciidoctor tasks can be configured to run AsciidoctorJ conversions in
  or out of process. Even when running in process AsciidoctorJ will be on
  an isolated classpath.
- Tasks support parallel mode which will run each backend (or in the case
  of Epub, each output format) in a separate worker. This behevaiour can
  be turned off in which case only one Asciidoctor instance is used to run
  all conversions in sequence.
- For cases where Gradle's idea of supplementing the classpath for workers
  do fail, there is a special `inProcess = JAVA_EXEC` that will run the
  conversion out of process, albeit less efficient than an out-of-process
  worker.
- Due to Gradle API classpath leakage, builds with Gradle 4.0-4.2 will
  always run in `JAVA_EXEC` mode to prevent issues.
- `AsciidoctorJPdf` plugin has been added which adds a single
  `asciidoctorPdf` task and configures it accordingly to PDF behaviour.
  It also sets a default version of the `asciidoctorj-pdf` dependency.
- Backends and separateOutputDirs are configured via an outputOptions
  closure or action.
- `AsciidoctorJEpub` plugin has been added which adds a single
  `asciidoctorEpub` task and configures it accordingly to EPUB behaviour.
  It also sets a default version of the `asciidoctorj-epub` dependency.
- Epub output formats can be set via the `ebookFormats` method.
- Additional Kindlegen plugin which is invoked by EPUB for when the format
  is KF8. The plugin will bootstrap kindlegen on all supported platforms.
- Work around gradle/gradle#3698 and Xerces API
  clash by running EPub conversions using `inProcess = JAVA_EXEC`.
- All methods on the new task classes that take closures as parameters now
  also have equivalent Action parameters (asciidoctor#236).
- All new tasks are supportd by integration tests and compatibility tests. (asciidoctor#180)

Known issues:
- Intermittent failures in tests related to bad file descriptor. Could be
  similar to asciidoctor/asciidoctorj#442.
- EPUB3 + KF8 in one task (PendingFeature). Both formats in one task is
  currently failing. The exact failure message depends on which order
  (KF8+EPUB3 or EPUB3+KF8) the conversion takes place in.
- KF8 conversions fails under Windows.
  Related to asciidoctor/asciidoctorj#659 & jruby/jruby#4943.

Backwards compatibility and migration:
- Legacy code moved to 'org.asciidoctor.gradle.compat' package,
  but get AsciidoctorTask in same package for compatibility purpose.
- Renamed AsciidoctorPlugin to AsciidoctorCompatibilityPlugin.
- Legacy plugin cannot be used with other Asciidoctor plugins within
  the same project.
- Existing 1.5.x deprecated methods has been removed from legacy
  AsciidoctorTask.

General:
- Use 'base' plugin model for Asciidoctor plugins.
- Only support Gradle 4.0+.
- Only support JDK8+.
- For Gradle 4.5+ migration messages are controlled via `--warning-mode`.
- For Gradle 4.0-4.4 migration messages are controlled via `--info`.
- Additional text will be displayed on Gradle Plugin Portal for during
  alpha & beta releases.
- Compatibility testing has been added and initialy against Gradle
  versions 4.0.2, 4.3.1 & 4.6. (For JDK10 only test against 4.7).
- JDK compatibility testing are done from JDK8 -> JDK10 (Travis)
- Codenarc settings has been updated to find configuration from within
  subprojects.
- Updated license headers to include 2018.
- Integration tests utilises an offline Ivy repository (via Ivypot plugin)
  to reduce bandwith usage and test time.
- AsciidoctorJ, GroovyDSL etc. versions are defined in code and read by the
  build script. This provides one point of definition and ensure that code
  can have appropriate default versions.

New generation plugins and tasks:
- New (JVM) AsciidoctorJ extension can be added to both project & tasks.
  Extension in task can be used to override global settings from the
  project extension. It takes into account some of the ideas @manuelprinz
  had for asciidoctor#231 for is much more extensive.
- Extension has support for Asciidoctor verbose mode (asciidoctor#233).
  If `verboseMode` is set then a temporary file will be created and made
  part of Asciidoctor `requires`.
- JRuby version can be controlled at both project and task level. If no
  version is specified at either level, the default JRuby version that
  AsciidoctorJ depends on will be used.
- GroovyDSL extensions are now registered eitehr on the project extension
  or the task extensions. The extensions are only loaded within a worker
  instance. The asciidoctor task is unloaded at the end of the worker and
  with it the extensions. (asciidoctor#166)
- AsciidoctorTask differentitates between top-level sources, secondary
  sources and resources in order to have a better idea of being
  out-of-date. (asciidoctor#185)
- It is possible to control whether resources should be copied or not. This
  allows a build to better deal with a backend such as PDF, which do not
  need resources to be copied.
- It is possible to perform the conversion from an intermediate working
  directory, which allows for a source directory to be kept pristine from
  intermediate artifacts generated from extensions such as ditaa.
- Using a worker approach for running Asciidoctor instances. (asciidoctor#220)
- Asciidoctor tasks can be configured to run AsciidoctorJ conversions in
  or out of process. Even when running in process AsciidoctorJ will be on
  an isolated classpath.
- Tasks support parallel mode which will run each backend (or in the case
  of Epub, each output format) in a separate worker. This behevaiour can
  be turned off in which case only one Asciidoctor instance is used to run
  all conversions in sequence.
- For cases where Gradle's idea of supplementing the classpath for workers
  do fail, there is a special `inProcess = JAVA_EXEC` that will run the
  conversion out of process, albeit less efficient than an out-of-process
  worker.
- Due to Gradle API classpath leakage, builds with Gradle 4.0-4.2 will
  always run in `JAVA_EXEC` mode to prevent issues.
- `AsciidoctorJPdf` plugin has been added which adds a single
  `asciidoctorPdf` task and configures it accordingly to PDF behaviour.
  It also sets a default version of the `asciidoctorj-pdf` dependency.
- Backends and separateOutputDirs are configured via an outputOptions
  closure or action.
- `AsciidoctorJEpub` plugin has been added which adds a single
  `asciidoctorEpub` task and configures it accordingly to EPUB behaviour.
  It also sets a default version of the `asciidoctorj-epub` dependency.
- Epub output formats can be set via the `ebookFormats` method.
- Additional Kindlegen plugin which is invoked by EPUB for when the format
  is KF8. The plugin will bootstrap kindlegen on all supported platforms.
- Work around gradle/gradle#3698 and Xerces API
  clash by running EPub conversions using `inProcess = JAVA_EXEC`.
- All methods on the new task classes that take closures as parameters now
  also have equivalent Action parameters (asciidoctor#236).
- All new tasks are supportd by integration tests and compatibility tests. (asciidoctor#180)

Known issues:
- Intermittent failures in tests related to bad file descriptor. Could be
  similar to asciidoctor/asciidoctorj#442.
- EPUB3 + KF8 in one task (PendingFeature). Both formats in one task is
  currently failing. The exact failure message depends on which order
  (KF8+EPUB3 or EPUB3+KF8) the conversion takes place in.
- KF8 conversions fails under Windows.
  Related to asciidoctor/asciidoctorj#659 & jruby/jruby#4943.

Backwards compatibility and migration:
- Legacy code moved to 'org.asciidoctor.gradle.compat' package,
  but get AsciidoctorTask in same package for compatibility purpose.
- Renamed AsciidoctorPlugin to AsciidoctorCompatibilityPlugin.
- Legacy plugin cannot be used with other Asciidoctor plugins within
  the same project.
- Existing 1.5.x deprecated methods has been removed from legacy
  AsciidoctorTask.

General:
- Use 'base' plugin model for Asciidoctor plugins.
- Only support Gradle 4.0+.
- Only support JDK8+.
- For Gradle 4.5+ migration messages are controlled via `--warning-mode`.
- For Gradle 4.0-4.4 migration messages are controlled via `--info`.
- Additional text will be displayed on Gradle Plugin Portal for during
  alpha & beta releases.
- Compatibility testing has been added and initialy against Gradle
  versions 4.0.2, 4.3.1 & 4.6. (For JDK10 only test against 4.7).
- JDK compatibility testing are done from JDK8 -> JDK10 (Travis)
- Codenarc settings has been updated to find configuration from within
  subprojects.
- Updated license headers to include 2018.
- Integration tests utilises an offline Ivy repository (via Ivypot plugin)
  to reduce bandwith usage and test time.
- AsciidoctorJ, GroovyDSL etc. versions are defined in code and read by the
  build script. This provides one point of definition and ensure that code
  can have appropriate default versions.

New generation plugins and tasks:
- New (JVM) AsciidoctorJ extension can be added to both project & tasks.
  Extension in task can be used to override global settings from the
  project extension. It takes into account some of the ideas @manuelprinz
  had for asciidoctor#231 for is much more extensive.
- Extension has support for Asciidoctor verbose mode (asciidoctor#233).
  If `verboseMode` is set then a temporary file will be created and made
  part of Asciidoctor `requires`.
- JRuby version can be controlled at both project and task level. If no
  version is specified at either level, the default JRuby version that
  AsciidoctorJ depends on will be used.
- GroovyDSL extensions are now registered eitehr on the project extension
  or the task extensions. The extensions are only loaded within a worker
  instance. The asciidoctor task is unloaded at the end of the worker and
  with it the extensions. (asciidoctor#166)
- AsciidoctorTask differentitates between top-level sources, secondary
  sources and resources in order to have a better idea of being
  out-of-date. (asciidoctor#185)
- It is possible to control whether resources should be copied or not. This
  allows a build to better deal with a backend such as PDF, which do not
  need resources to be copied.
- It is possible to perform the conversion from an intermediate working
  directory, which allows for a source directory to be kept pristine from
  intermediate artifacts generated from extensions such as ditaa.
- Using a worker approach for running Asciidoctor instances. (asciidoctor#220)
- Asciidoctor tasks can be configured to run AsciidoctorJ conversions in
  or out of process. Even when running in process AsciidoctorJ will be on
  an isolated classpath.
- Tasks support parallel mode which will run each backend (or in the case
  of Epub, each output format) in a separate worker. This behevaiour can
  be turned off in which case only one Asciidoctor instance is used to run
  all conversions in sequence.
- For cases where Gradle's idea of supplementing the classpath for workers
  do fail, there is a special `inProcess = JAVA_EXEC` that will run the
  conversion out of process, albeit less efficient than an out-of-process
  worker.
- Due to Gradle API classpath leakage, builds with Gradle 4.0-4.2 will
  always run in `JAVA_EXEC` mode to prevent issues.
- `AsciidoctorJPdf` plugin has been added which adds a single
  `asciidoctorPdf` task and configures it accordingly to PDF behaviour.
  It also sets a default version of the `asciidoctorj-pdf` dependency.
- Backends and separateOutputDirs are configured via an outputOptions
  closure or action.
- `AsciidoctorJEpub` plugin has been added which adds a single
  `asciidoctorEpub` task and configures it accordingly to EPUB behaviour.
  It also sets a default version of the `asciidoctorj-epub` dependency.
- Epub output formats can be set via the `ebookFormats` method.
- Additional Kindlegen plugin which is invoked by EPUB for when the format
  is KF8. The plugin will bootstrap kindlegen on all supported platforms.
- Work around gradle/gradle#3698 and Xerces API
  clash by running EPub conversions using `inProcess = JAVA_EXEC`.
- All methods on the new task classes that take closures as parameters now
  also have equivalent Action parameters (asciidoctor#236).
- All new tasks are supportd by integration tests and compatibility tests. (asciidoctor#180)

Known issues:
- Intermittent failures in tests related to bad file descriptor. Could be
  similar to asciidoctor/asciidoctorj#442.
- EPUB3 + KF8 in one task (PendingFeature). Both formats in one task is
  currently failing. The exact failure message depends on which order
  (KF8+EPUB3 or EPUB3+KF8) the conversion takes place in.
- KF8 conversions fails under Windows.
  Related to asciidoctor/asciidoctorj#659 & jruby/jruby#4943.

Backwards compatibility and migration:
- Legacy code moved to 'org.asciidoctor.gradle.compat' package,
  but get AsciidoctorTask in same package for compatibility purpose.
- Renamed AsciidoctorPlugin to AsciidoctorCompatibilityPlugin.
- Legacy plugin cannot be used with other Asciidoctor plugins within
  the same project.
- Existing 1.5.x deprecated methods has been removed from legacy
  AsciidoctorTask.

General:
- Use 'base' plugin model for Asciidoctor plugins.
- Only support Gradle 4.0+.
- Only support JDK8+.
- For Gradle 4.5+ migration messages are controlled via `--warning-mode`.
- For Gradle 4.0-4.4 migration messages are controlled via `--info`.
- Additional text will be displayed on Gradle Plugin Portal for during
  alpha & beta releases.
- Compatibility testing has been added and initialy against Gradle
  versions 4.0.2, 4.3.1 & 4.6. (For JDK10 only test against 4.7).
- JDK compatibility testing are done from JDK8 -> JDK10 (Travis)
- Codenarc settings has been updated to find configuration from within
  subprojects.
- Updated license headers to include 2018.
- Integration tests utilises an offline Ivy repository (via Ivypot plugin)
  to reduce bandwith usage and test time.
- AsciidoctorJ, GroovyDSL etc. versions are defined in code and read by the
  build script. This provides one point of definition and ensure that code
  can have appropriate default versions.

New generation plugins and tasks:
- New (JVM) AsciidoctorJ extension can be added to both project & tasks.
  Extension in task can be used to override global settings from the
  project extension. It takes into account some of the ideas @manuelprinz
  had for asciidoctor#231 for is much more extensive.
- Extension has support for Asciidoctor verbose mode (asciidoctor#233).
  If `verboseMode` is set then a temporary file will be created and made
  part of Asciidoctor `requires`.
- JRuby version can be controlled at both project and task level. If no
  version is specified at either level, the maximum of default the JRuby
  version that AsciidoctorJ depends on and a coded minimum safe version
  of JRuby, will be used. The default minimum JRuby is 9.0.5.0
- GroovyDSL extensions are now registered eitehr on the project extension
  or the task extensions. The extensions are only loaded within a worker
  instance. The asciidoctor task is unloaded at the end of the worker and
  with it the extensions. (asciidoctor#166)
- AsciidoctorTask differentitates between top-level sources, secondary
  sources and resources in order to have a better idea of being
  out-of-date. (asciidoctor#185)
- It is possible to control whether resources should be copied or not. This
  allows a build to better deal with a backend such as PDF, which do not
  need resources to be copied.
- It is possible to perform the conversion from an intermediate working
  directory, which allows for a source directory to be kept pristine from
  intermediate artifacts generated from extensions such as ditaa.
- Using a worker approach for running Asciidoctor instances. (asciidoctor#220)
- Asciidoctor tasks can be configured to run AsciidoctorJ conversions in
  or out of process. Even when running in process AsciidoctorJ will be on
  an isolated classpath.
- Tasks support parallel mode which will run each backend (or in the case
  of Epub, each output format) in a separate worker. This behevaiour can
  be turned off in which case only one Asciidoctor instance is used to run
  all conversions in sequence.
- For cases where Gradle's idea of supplementing the classpath for workers
  do fail, there is a special `inProcess = JAVA_EXEC` that will run the
  conversion out of process, albeit less efficient than an out-of-process
  worker.
- Due to Gradle API classpath leakage, builds with Gradle 4.0-4.2 will
  always run in `JAVA_EXEC` mode to prevent issues.
- `AsciidoctorJPdf` plugin has been added which adds a single
  `asciidoctorPdf` task and configures it accordingly to PDF behaviour.
  It also sets a default version of the `asciidoctorj-pdf` dependency.
- If the PDF backend is used and the JRuby version starts with '9.x'
  then place SnakeYaml v1.13 on the classpath.
- Backends and separateOutputDirs are configured via an outputOptions
  closure or action.
- `AsciidoctorJEpub` plugin has been added which adds a single
  `asciidoctorEpub` task and configures it accordingly to EPUB behaviour.
  It also sets a default version of the `asciidoctorj-epub` dependency.
- Epub output formats can be set via the `ebookFormats` method.
- Additional Kindlegen plugin which is invoked by EPUB for when the format
  is KF8. The plugin will bootstrap kindlegen on all supported platforms.
- Work around gradle/gradle#3698 and Xerces API
  clash by running EPub conversions using `inProcess = JAVA_EXEC`.
- All methods on the new task classes that take closures as parameters now
  also have equivalent Action parameters (asciidoctor#236).
- All new tasks are supportd by integration tests and compatibility tests. (asciidoctor#180)

Known issues:
- Intermittent failures in tests related to bad file descriptor. Could be
  similar to asciidoctor/asciidoctorj#442.
- EPUB3 + KF8 in one task (PendingFeature). Both formats in one task is
  currently failing. The exact failure message depends on which order
  (KF8+EPUB3 or EPUB3+KF8) the conversion takes place in.
- KF8 conversions fails under Windows.
  Related to asciidoctor/asciidoctorj#659 & jruby/jruby#4943.

Backwards compatibility and migration:
- Legacy code moved to 'org.asciidoctor.gradle.compat' package,
  but get AsciidoctorTask in same package for compatibility purpose.
- Renamed AsciidoctorPlugin to AsciidoctorCompatibilityPlugin.
- Legacy plugin cannot be used with other Asciidoctor plugins within
  the same project.
- Existing 1.5.x deprecated methods has been removed from legacy
  AsciidoctorTask.

General:
- Use 'base' plugin model for Asciidoctor plugins.
- Only support Gradle 4.0+.
- Only support JDK8+.
- For Gradle 4.5+ migration messages are controlled via `--warning-mode`.
- For Gradle 4.0-4.4 migration messages are controlled via `--info`.
- Additional text will be displayed on Gradle Plugin Portal for during
  alpha & beta releases.
- Compatibility testing has been added and initialy against Gradle
  versions 4.0.2, 4.3.1 & 4.6. (For JDK10 only test against 4.7).
- Some integration tests contain JRuby compatibility tests. Current test
  set is 1.7.27, 9.0.50, 9.1.17.0, 9.2.0.0.
- JDK compatibility testing are done from JDK8 -> JDK10 (Travis)
- Codenarc settings has been updated to find configuration from within
  subprojects.
- Updated license headers to include 2018.
- Integration tests utilises an offline Ivy repository (via Ivypot plugin)
  to reduce bandwith usage and test time.
- AsciidoctorJ, GroovyDSL etc. versions are defined in code and read by the
  build script. This provides one point of definition and ensure that code
  can have appropriate default versions.

New generation plugins and tasks:
- New (JVM) AsciidoctorJ extension can be added to both project & tasks.
  Extension in task can be used to override global settings from the
  project extension. It takes into account some of the ideas @manuelprinz
  had for asciidoctor#231 for is much more extensive.
- Extension has support for Asciidoctor verbose mode (asciidoctor#233).
  If `verboseMode` is set then a temporary file will be created and made
  part of Asciidoctor `requires`.
- JRuby version can be controlled at both project and task level. If no
  version is specified at either level, the maximum of default the JRuby
  version that AsciidoctorJ depends on and a coded minimum safe version
  of JRuby, will be used. The default minimum JRuby is 9.0.5.0
- GroovyDSL extensions are now registered eitehr on the project extension
  or the task extensions. The extensions are only loaded within a worker
  instance. The asciidoctor task is unloaded at the end of the worker and
  with it the extensions. (asciidoctor#166)
- AsciidoctorTask differentitates between top-level sources, secondary
  sources and resources in order to have a better idea of being
  out-of-date. (asciidoctor#185)
- It is possible to control whether resources should be copied or not. This
  allows a build to better deal with a backend such as PDF, which do not
  need resources to be copied.
- It is possible to perform the conversion from an intermediate working
  directory, which allows for a source directory to be kept pristine from
  intermediate artifacts generated from extensions such as ditaa.
- Using a worker approach for running Asciidoctor instances. (asciidoctor#220)
- Asciidoctor tasks can be configured to run AsciidoctorJ conversions in
  or out of process. Even when running in process AsciidoctorJ will be on
  an isolated classpath.
- Tasks support parallel mode which will run each backend (or in the case
  of Epub, each output format) in a separate worker. This behevaiour can
  be turned off in which case only one Asciidoctor instance is used to run
  all conversions in sequence.
- For cases where Gradle's idea of supplementing the classpath for workers
  do fail, there is a special `inProcess = JAVA_EXEC` that will run the
  conversion out of process, albeit less efficient than an out-of-process
  worker.
- Due to Gradle API classpath leakage, builds with Gradle 4.0-4.2 will
  always run in `JAVA_EXEC` mode to prevent issues.
- `AsciidoctorJPdf` plugin has been added which adds a single
  `asciidoctorPdf` task and configures it accordingly to PDF behaviour.
  It also sets a default version of the `asciidoctorj-pdf` dependency.
- If the PDF backend is used and the JRuby version starts with '9.x'
  then place SnakeYaml v1.13 on the classpath.
- Backends and separateOutputDirs are configured via an outputOptions
  closure or action.
- `AsciidoctorJEpub` plugin has been added which adds a single
  `asciidoctorEpub` task and configures it accordingly to EPUB behaviour.
  It also sets a default version of the `asciidoctorj-epub` dependency.
- Epub output formats can be set via the `ebookFormats` method.
- Additional Kindlegen plugin which is invoked by EPUB for when the format
  is KF8. The plugin will bootstrap kindlegen on all supported platforms.
- Work around gradle/gradle#3698 and Xerces API
  clash by running EPub conversions using `inProcess = JAVA_EXEC`.
- All methods on the new task classes that take closures as parameters now
  also have equivalent Action parameters (asciidoctor#236).
- All new tasks are supportd by integration tests and compatibility tests. (asciidoctor#180)

Known issues:
- Intermittent failures in tests related to bad file descriptor. Could be
  similar to asciidoctor/asciidoctorj#442.
- EPUB3 + KF8 in one task (PendingFeature). Both formats in one task is
  currently failing. The exact failure message depends on which order
  (KF8+EPUB3 or EPUB3+KF8) the conversion takes place in.
- KF8 conversions fails under Windows.
  Related to asciidoctor/asciidoctorj#659 & jruby/jruby#4943.
- Does not work with JDK9 (but does with JDK10).

Backwards compatibility and migration:
- Legacy code moved to 'org.asciidoctor.gradle.compat' package,
  but get AsciidoctorTask in same package for compatibility purpose.
- Renamed AsciidoctorPlugin to AsciidoctorCompatibilityPlugin.
- Legacy plugin cannot be used with other Asciidoctor plugins within
  the same project.
- Existing 1.5.x deprecated methods has been removed from legacy
  AsciidoctorTask.

General:
- Use 'base' plugin model for Asciidoctor plugins.
- Only support Gradle 4.0+.
- Only support JDK8+.
- For Gradle 4.5+ migration messages are controlled via `--warning-mode`.
- For Gradle 4.0-4.4 migration messages are controlled via `--info`.
- Additional text will be displayed on Gradle Plugin Portal for during
  alpha & beta releases.
- Compatibility testing has been added and initialy against Gradle
  versions 4.0.2, 4.3.1 & 4.6. (For JDK10 only test against 4.7).
- Some integration tests contain JRuby compatibility tests. Current test
  set is 1.7.27, 9.0.50, 9.1.17.0, 9.2.0.0.
- JDK compatibility testing are done from JDK8 -> JDK10 (Travis)
- Codenarc settings has been updated to find configuration from within
  subprojects.
- Updated license headers to include 2018.
- Integration tests utilises an offline Ivy repository (via Ivypot plugin)
  to reduce bandwith usage and test time.
- AsciidoctorJ, GroovyDSL etc. versions are defined in code and read by the
  build script. This provides one point of definition and ensure that code
  can have appropriate default versions.

New generation plugins and tasks:
- New (JVM) AsciidoctorJ extension can be added to both project & tasks.
  Extension in task can be used to override global settings from the
  project extension. It takes into account some of the ideas @manuelprinz
  had for asciidoctor#231 for is much more extensive.
- Extension has support for Asciidoctor verbose mode (asciidoctor#233).
  If `verboseMode` is set then a temporary file will be created and made
  part of Asciidoctor `requires`.
- JRuby version can be controlled at both project and task level. If no
  version is specified at either level, the maximum of default the JRuby
  version that AsciidoctorJ depends on and a coded minimum safe version
  of JRuby, will be used. The default minimum JRuby is 9.0.5.0
- GroovyDSL extensions are now registered eitehr on the project extension
  or the task extensions. The extensions are only loaded within a worker
  instance. The asciidoctor task is unloaded at the end of the worker and
  with it the extensions. (asciidoctor#166)
- AsciidoctorTask differentitates between top-level sources, secondary
  sources and resources in order to have a better idea of being
  out-of-date. (asciidoctor#185)
- It is possible to control whether resources should be copied or not. This
  allows a build to better deal with a backend such as PDF, which do not
  need resources to be copied.
- It is possible to perform the conversion from an intermediate working
  directory, which allows for a source directory to be kept pristine from
  intermediate artifacts generated from extensions such as ditaa.
- Using a worker approach for running Asciidoctor instances. (asciidoctor#220)
- Asciidoctor tasks can be configured to run AsciidoctorJ conversions in
  or out of process. Even when running in process AsciidoctorJ will be on
  an isolated classpath.
- Tasks support parallel mode which will run each backend (or in the case
  of Epub, each output format) in a separate worker. This behevaiour can
  be turned off in which case only one Asciidoctor instance is used to run
  all conversions in sequence.
- For cases where Gradle's idea of supplementing the classpath for workers
  do fail, there is a special `inProcess = JAVA_EXEC` that will run the
  conversion out of process, albeit less efficient than an out-of-process
  worker.
- Due to Gradle API classpath leakage, builds with Gradle 4.0-4.2 will
  always run in `JAVA_EXEC` mode to prevent issues.
- `AsciidoctorJPdf` plugin has been added which adds a single
  `asciidoctorPdf` task and configures it accordingly to PDF behaviour.
  It also sets a default version of the `asciidoctorj-pdf` dependency.
- If the PDF backend is used and the JRuby version starts with '9.x'
  then place SnakeYaml v1.13 on the classpath.
- Backends and separateOutputDirs are configured via an outputOptions
  closure or action.
- `AsciidoctorJEpub` plugin has been added which adds a single
  `asciidoctorEpub` task and configures it accordingly to EPUB behaviour.
  It also sets a default version of the `asciidoctorj-epub` dependency.
- Epub output formats can be set via the `ebookFormats` method.
- Additional Kindlegen plugin which is invoked by EPUB for when the format
  is KF8. The plugin will bootstrap kindlegen on all supported platforms.
- Work around gradle/gradle#3698 and Xerces API
  clash by running EPub conversions using `inProcess = JAVA_EXEC`.
- All methods on the new task classes that take closures as parameters now
  also have equivalent Action parameters (asciidoctor#236).
- All new tasks are supportd by integration tests and compatibility tests. (asciidoctor#180)

Known issues:
- Intermittent failures in tests related to bad file descriptor. Could be
  similar to asciidoctor/asciidoctorj#442.
- EPUB3 + KF8 in one task (PendingFeature). Both formats in one task is
  currently failing. The exact failure message depends on which order
  (KF8+EPUB3 or EPUB3+KF8) the conversion takes place in.
- KF8 conversions fails under Windows.
  Related to asciidoctor/asciidoctorj#659 & jruby/jruby#4943.
- Does not work with JDK9 (but does with JDK10).

Backwards compatibility and migration:
- Legacy code moved to 'org.asciidoctor.gradle.compat' package,
  but get AsciidoctorTask in same package for compatibility purpose.
- Renamed AsciidoctorPlugin to AsciidoctorCompatibilityPlugin.
- Legacy plugin cannot be used with other Asciidoctor plugins within
  the same project.
- Existing 1.5.x deprecated methods has been removed from legacy
  AsciidoctorTask.

General:
- The version series is 2.0.0. It will be kept as alpha releases for
  a while.
- Use 'base' plugin model for Asciidoctor plugins.
- Only support Gradle 4.0+.
- Only support JDK8+.
- For Gradle 4.5+ migration messages are controlled via `--warning-mode`.
- For Gradle 4.0-4.4 migration messages are controlled via `--info`.
- Additional text will be displayed on Gradle Plugin Portal for during
  alpha & beta releases.
- Compatibility testing has been added and initialy against Gradle
  versions 4.0.2, 4.3.1 & 4.6. (For JDK10 only test against 4.7).
- Some integration tests contain JRuby compatibility tests. Current test
  set is 1.7.27, 9.0.50, 9.1.17.0, 9.2.0.0.
- JDK compatibility testing are done from JDK8 -> JDK10 (Travis)
- Codenarc settings has been updated to find configuration from within
  subprojects.
- Updated license headers to include 2018.
- Integration tests utilises an offline Ivy repository (via Ivypot plugin)
  to reduce bandwith usage and test time.
- AsciidoctorJ, GroovyDSL etc. versions are defined in code and read by the
  build script. This provides one point of definition and ensure that code
  can have appropriate default versions.
- Test versions of JRuby and AsciidoctorJ is controlled via test fixtures.

New generation AsciidoctorJ plugins and tasks:
- New (JVM) AsciidoctorJ extension can be added to both project & tasks.
  Extension in task can be used to override global settings from the
  project extension. It takes into account some of the ideas @manuelprinz
  had for asciidoctor#231 for is much more extensive.
- Extension has support for Asciidoctor verbose mode (asciidoctor#233).
  If `verboseMode` is set then a temporary file will be created and made
  part of Asciidoctor `requires`.
- AsciidoctorJ v1.6.0-alpha.6 is the default version, but it is possible
  to set a 1.5.x version if required.
- JRuby version can be controlled at both project and task level. If no
  version is specified at either level, the maximum of default the JRuby
  version that AsciidoctorJ depends on and a coded minimum safe version
  of JRuby, will be used.
- AsciidoctorJExtension maintains it's own detached configuration which
  can be fine turned via resolution strategies for edge cases.
- the `org.asciidoctor.jvm.base` plugin adds a dependency report
  specifically for the detached configuration.
- GroovyDSL extensions are now registered eitehr on the project extension
  or the task extensions. The extensions are only loaded within a worker
  instance. The asciidoctor task is unloaded at the end of the worker and
  with it the extensions. (asciidoctor#166)
- AsciidoctorTask differentitates between top-level sources, secondary
  sources and resources in order to have a better idea of being
  out-of-date. (asciidoctor#185)
- It is possible to control whether resources should be copied or not. This
  allows a build to better deal with a backend such as PDF, which do not
  need resources to be copied.
- It is possible to perform the conversion from an intermediate working
  directory, which allows for a source directory to be kept pristine from
  intermediate artifacts generated from extensions such as ditaa.
- Using a worker approach for running Asciidoctor instances. (asciidoctor#220)
- Asciidoctor tasks can be configured to run AsciidoctorJ conversions in
  or out of process. Even when running in process AsciidoctorJ will be on
  an isolated classpath.
- Tasks support parallel mode which will run each backend (or in the case
  of Epub, each output format) in a separate worker. This behevaiour can
  be turned off in which case only one Asciidoctor instance is used to run
  all conversions in sequence.
- For cases where Gradle's idea of supplementing the classpath for workers
  do fail, there is a special `inProcess = JAVA_EXEC` that will run the
  conversion out of process, albeit less efficient than an out-of-process
  worker.
- Due to Gradle API classpath leakage, builds with Gradle 4.0-4.2 will
  always run in `JAVA_EXEC` mode to prevent issues.
- `AsciidoctorJPdf` plugin has been added which adds a single
  `asciidoctorPdf` task and configures it accordingly to PDF behaviour.
  It also sets a default version of the `asciidoctorj-pdf` dependency.
- If the PDF backend is used and the JRuby version starts with '9.x'
  then place SnakeYaml v1.13 on the classpath.
- Backends and separateOutputDirs are configured via an outputOptions
  closure or action.
- `AsciidoctorJEpub` plugin has been added which adds a single
  `asciidoctorEpub` task and configures it accordingly to EPUB behaviour.
  It also sets a default version of the `asciidoctorj-epub` dependency.
- Epub output formats can be set via the `ebookFormats` method.
- Additional Kindlegen plugin which is invoked by EPUB for when the format
  is KF8. The plugin will bootstrap kindlegen on all supported platforms.
- Work around gradle/gradle#3698 and Xerces API
  clash by running EPub conversions using `inProcess = JAVA_EXEC`.
- All methods on the new task classes that take closures as parameters now
  also have equivalent Action parameters (asciidoctor#236).
- All new tasks are supportd by integration tests and compatibility tests. (asciidoctor#180)
- Various tests use a combination of JRuby & AsciidoctorJ versions to test
  compatibility at the integration test level.

Known issues:
- Intermittent failures in tests related to bad file descriptor. Could be
  similar to asciidoctor/asciidoctorj#442.
- EPUB3 + KF8 in one task (PendingFeature). Both formats in one task is
  currently failing. The exact failure message depends on which order
  (KF8+EPUB3 or EPUB3+KF8) the conversion takes place in.
- KF8 conversions fails under Windows.
  Related to asciidoctor/asciidoctorj#659 & jruby/jruby#4943.
- Does not work with JDK9 (but does with JDK10).

Backwards compatibility and migration:
- Legacy code moved to 'org.asciidoctor.gradle.compat' package,
  but get AsciidoctorTask in same package for compatibility purpose.
- Renamed AsciidoctorPlugin to AsciidoctorCompatibilityPlugin.
- Legacy plugin cannot be used with other Asciidoctor plugins within
  the same project.
- Existing 1.5.x deprecated methods has been removed from legacy
  AsciidoctorTask.

General:
- The version series is 2.0.0. It will be kept as alpha releases for
  a while.
- Use 'base' plugin model for Asciidoctor plugins.
- Only support Gradle 4.0+.
- Only support JDK8+.
- For Gradle 4.5+ migration messages are controlled via `--warning-mode`.
- For Gradle 4.0-4.4 migration messages are controlled via `--info`.
- Additional text will be displayed on Gradle Plugin Portal for during
  alpha & beta releases.
- Compatibility testing has been added and initialy against Gradle
  versions 4.0.2, 4.3.1 & 4.6. (For JDK10 only test against 4.7).
- Some integration tests contain JRuby compatibility tests. Current test
  set is 1.7.27, 9.0.50, 9.1.17.0, 9.2.0.0.
- JDK compatibility testing are done from JDK8 -> JDK10 (Travis)
- Codenarc settings has been updated to find configuration from within
  subprojects.
- Updated license headers to include 2018.
- Integration tests utilises an offline Ivy repository (via Ivypot plugin)
  to reduce bandwith usage and test time.
- AsciidoctorJ, GroovyDSL etc. versions are defined in code and read by the
  build script. This provides one point of definition and ensure that code
  can have appropriate default versions.
- Test versions of JRuby and AsciidoctorJ is controlled via test fixtures.

New generation AsciidoctorJ plugins and tasks:
- New (JVM) AsciidoctorJ extension can be added to both project & tasks.
  Extension in task can be used to override global settings from the
  project extension. It takes into account some of the ideas @manuelprinz
  had for asciidoctor#231 for is much more extensive.
- Extension has support for Asciidoctor verbose mode (asciidoctor#233).
  If `verboseMode` is set then a temporary file will be created and made
  part of Asciidoctor `requires`.
- AsciidoctorJ v1.6.0-alpha.6 is the default version, but it is possible
  to set a 1.5.x version if required.
- JRuby version can be controlled at both project and task level. If no
  version is specified at either level, the maximum of default the JRuby
  version that AsciidoctorJ depends on and a coded minimum safe version
  of JRuby, will be used.
- AsciidoctorJExtension maintains it's own detached configuration which
  can be fine turned via resolution strategies for edge cases.
- the `org.asciidoctor.jvm.base` plugin adds a dependency report
  specifically for the detached configuration.
- GroovyDSL extensions are now registered eitehr on the project extension
  or the task extensions. The extensions are only loaded within a worker
  instance. The asciidoctor task is unloaded at the end of the worker and
  with it the extensions. (asciidoctor#166)
- AsciidoctorTask differentitates between top-level sources, secondary
  sources and resources in order to have a better idea of being
  out-of-date. (asciidoctor#185)
- It is possible to control whether resources should be copied or not. This
  allows a build to better deal with a backend such as PDF, which do not
  need resources to be copied.
- It is possible to perform the conversion from an intermediate working
  directory, which allows for a source directory to be kept pristine from
  intermediate artifacts generated from extensions such as ditaa.
- Using a worker approach for running Asciidoctor instances. (asciidoctor#220)
- Asciidoctor tasks can be configured to run AsciidoctorJ conversions in
  or out of process. Even when running in process AsciidoctorJ will be on
  an isolated classpath.
- Tasks support parallel mode which will run each backend (or in the case
  of Epub, each output format) in a separate worker. This behevaiour can
  be turned off in which case only one Asciidoctor instance is used to run
  all conversions in sequence.
- For cases where Gradle's idea of supplementing the classpath for workers
  do fail, there is a special `inProcess = JAVA_EXEC` that will run the
  conversion out of process, albeit less efficient than an out-of-process
  worker.
- Due to Gradle API classpath leakage, builds with Gradle 4.0-4.2 will
  always run in `JAVA_EXEC` mode to prevent issues.
- `AsciidoctorJPdf` plugin has been added which adds a single
  `asciidoctorPdf` task and configures it accordingly to PDF behaviour.
  It also sets a default version of the `asciidoctorj-pdf` dependency.
- If the PDF backend is used and the JRuby version starts with '9.x'
  then place SnakeYaml v1.13 on the classpath.
- Backends and separateOutputDirs are configured via an outputOptions
  closure or action.
- `AsciidoctorJEpub` plugin has been added which adds a single
  `asciidoctorEpub` task and configures it accordingly to EPUB behaviour.
  It also sets a default version of the `asciidoctorj-epub` dependency.
- Epub output formats can be set via the `ebookFormats` method.
- Additional Kindlegen plugin which is invoked by EPUB for when the format
  is KF8. The plugin will bootstrap kindlegen on all supported platforms.
- Work around gradle/gradle#3698 and Xerces API
  clash by running EPub conversions using `inProcess = JAVA_EXEC`.
- All methods on the new task classes that take closures as parameters now
  also have equivalent Action parameters (asciidoctor#236).
- All new tasks are supportd by integration tests and compatibility tests. (asciidoctor#180)
- Various tests use a combination of JRuby & AsciidoctorJ versions to test
  compatibility at the integration test level.

Known issues:
- Intermittent failures in tests related to bad file descriptor. Could be
  similar to asciidoctor/asciidoctorj#442.
- EPUB3 + KF8 in one task (PendingFeature). Both formats in one task is
  currently failing. The exact failure message depends on which order
  (KF8+EPUB3 or EPUB3+KF8) the conversion takes place in.
- KF8 conversions fails under Windows.
  Related to asciidoctor/asciidoctorj#659 & jruby/jruby#4943.
- Does not work with JDK9 (but does with JDK10).

Backwards compatibility and migration:
- Legacy code moved to 'org.asciidoctor.gradle.compat' package,
  but get AsciidoctorTask in same package for compatibility purpose.
- Renamed AsciidoctorPlugin to AsciidoctorCompatibilityPlugin.
- Legacy plugin cannot be used with other Asciidoctor plugins within
  the same project.
- Existing 1.5.x deprecated methods has been removed from legacy
  AsciidoctorTask.

General:
- The version series is 2.0.0. It will be kept as alpha releases for
  a while.
- Use 'base' plugin model for Asciidoctor plugins.
- Only support Gradle 4.0+.
- Only support JDK8+.
- For Gradle 4.5+ migration messages are controlled via `--warning-mode`.
- For Gradle 4.0-4.4 migration messages are controlled via `--info`.
- Additional text will be displayed on Gradle Plugin Portal for during
  alpha & beta releases.
- Compatibility testing has been added and initialy against Gradle
  versions 4.0.2, 4.3.1 & 4.6. (For JDK10 only test against 4.7).
- Some integration tests contain JRuby compatibility tests. Current test
  set is 1.7.27, 9.0.50, 9.1.17.0, 9.2.0.0.
- JDK compatibility testing are done from JDK8 -> JDK10 (Travis)
- Codenarc settings has been updated to find configuration from within
  subprojects.
- Updated license headers to include 2018.
- Integration tests utilises an offline Ivy repository (via Ivypot plugin)
  to reduce bandwith usage and test time.
- AsciidoctorJ, GroovyDSL etc. versions are defined in code and read by the
  build script. This provides one point of definition and ensure that code
  can have appropriate default versions.
- Test versions of JRuby and AsciidoctorJ is controlled via test fixtures.

New generation AsciidoctorJ plugins and tasks:
- New (JVM) AsciidoctorJ extension can be added to both project & tasks.
  Extension in task can be used to override global settings from the
  project extension. It takes into account some of the ideas @manuelprinz
  had for asciidoctor#231 for is much more extensive.
- Extension has support for Asciidoctor verbose mode (asciidoctor#233).
  If `verboseMode` is set then a temporary file will be created and made
  part of Asciidoctor `requires`.
- AsciidoctorJ v1.6.0-alpha.6 is the default version, but it is possible
  to set a 1.5.x version if required.
- JRuby version can be controlled at both project and task level. If no
  version is specified at either level, the maximum of default the JRuby
  version that AsciidoctorJ depends on and a coded minimum safe version
  of JRuby, will be used.
- AsciidoctorJExtension maintains it's own detached configuration which
  can be fine turned via resolution strategies for edge cases.
- the `org.asciidoctor.jvm.base` plugin adds a dependency report
  specifically for the detached configuration.
- GroovyDSL extensions are now registered eitehr on the project extension
  or the task extensions. The extensions are only loaded within a worker
  instance. The asciidoctor task is unloaded at the end of the worker and
  with it the extensions. (asciidoctor#166)
- AsciidoctorTask differentitates between top-level sources, secondary
  sources and resources in order to have a better idea of being
  out-of-date. (asciidoctor#185)
- It is possible to control whether resources should be copied or not. This
  allows a build to better deal with a backend such as PDF, which do not
  need resources to be copied.
- It is possible to perform the conversion from an intermediate working
  directory, which allows for a source directory to be kept pristine from
  intermediate artifacts generated from extensions such as ditaa.
- Using a worker approach for running Asciidoctor instances. (asciidoctor#220)
- Asciidoctor tasks can be configured to run AsciidoctorJ conversions in
  or out of process. Even when running in process AsciidoctorJ will be on
  an isolated classpath.
- Tasks support parallel mode which will run each backend (or in the case
  of Epub, each output format) in a separate worker. This behevaiour can
  be turned off in which case only one Asciidoctor instance is used to run
  all conversions in sequence.
- For cases where Gradle's idea of supplementing the classpath for workers
  do fail, there is a special `inProcess = JAVA_EXEC` that will run the
  conversion out of process, albeit less efficient than an out-of-process
  worker.
- Due to Gradle API classpath leakage, builds with Gradle 4.0-4.2 will
  always run in `JAVA_EXEC` mode to prevent issues.
- `AsciidoctorJPdf` plugin has been added which adds a single
  `asciidoctorPdf` task and configures it accordingly to PDF behaviour.
  It also sets a default version of the `asciidoctorj-pdf` dependency.
- If the PDF backend is used and the JRuby version starts with '9.x'
  then place SnakeYaml v1.13 on the classpath.
- Backends and separateOutputDirs are configured via an outputOptions
  closure or action.
- `AsciidoctorJEpub` plugin has been added which adds a single
  `asciidoctorEpub` task and configures it accordingly to EPUB behaviour.
  It also sets a default version of the `asciidoctorj-epub` dependency.
- Epub output formats can be set via the `ebookFormats` method.
- Additional Kindlegen plugin which is invoked by EPUB for when the format
  is KF8. The plugin will bootstrap kindlegen on all supported platforms.
- Work around gradle/gradle#3698 and Xerces API
  clash by running EPub conversions using `inProcess = JAVA_EXEC`.
- All methods on the new task classes that take closures as parameters now
  also have equivalent Action parameters (asciidoctor#236).
- All new tasks are supportd by integration tests and compatibility tests. (asciidoctor#180)
- Various tests use a combination of JRuby & AsciidoctorJ versions to test
  compatibility at the integration test level.

Known issues:
- Intermittent failures in tests related to bad file descriptor. Could be
  similar to asciidoctor/asciidoctorj#442.
- EPUB3 + KF8 in one task (PendingFeature). Both formats in one task is
  currently failing. The exact failure message depends on which order
  (KF8+EPUB3 or EPUB3+KF8) the conversion takes place in.
- KF8 conversions fails under Windows.
  Related to asciidoctor/asciidoctorj#659 & jruby/jruby#4943.
- Does not work with JDK9 (but does with JDK10).

Backwards compatibility and migration:
- Legacy code moved to 'org.asciidoctor.gradle.compat' package,
  but get AsciidoctorTask in same package for compatibility purpose.
- Renamed AsciidoctorPlugin to AsciidoctorCompatibilityPlugin.
- Legacy plugin cannot be used with other Asciidoctor plugins within
  the same project.
- Existing 1.5.x deprecated methods has been removed from legacy
  AsciidoctorTask.

General:
- The version series is 2.0.0. It will be kept as alpha releases for
  a while.
- Use 'base' plugin model for Asciidoctor plugins.
- Only support Gradle 4.0+.
- Only support JDK8+.
- For Gradle 4.5+ migration messages are controlled via `--warning-mode`.
- For Gradle 4.0-4.4 migration messages are controlled via `--info`.
- Additional text will be displayed on Gradle Plugin Portal for during
  alpha & beta releases.
- Compatibility testing has been added and initialy against Gradle
  versions 4.0.2, 4.3.1 & 4.6. (For JDK10 only test against 4.7).
- Some integration tests contain JRuby compatibility tests. Current test
  set is 1.7.27, 9.0.50, 9.1.17.0, 9.2.0.0.
- JDK compatibility testing are done from JDK8 -> JDK10 (Travis)
- Codenarc settings has been updated to find configuration from within
  subprojects.
- Updated license headers to include 2018.
- Integration tests utilises an offline Ivy repository (via Ivypot plugin)
  to reduce bandwith usage and test time.
- AsciidoctorJ, GroovyDSL etc. versions are defined in code and read by the
  build script. This provides one point of definition and ensure that code
  can have appropriate default versions.
- Test versions of JRuby and AsciidoctorJ is controlled via test fixtures.

New generation AsciidoctorJ plugins and tasks:
- New (JVM) AsciidoctorJ extension can be added to both project & tasks.
  Extension in task can be used to override global settings from the
  project extension. It takes into account some of the ideas @manuelprinz
  had for asciidoctor#231 for is much more extensive.
- Extension has support for Asciidoctor verbose mode (asciidoctor#233).
  If `verboseMode` is set then a temporary file will be created and made
  part of Asciidoctor `requires`.
- AsciidoctorJ v1.6.0-alpha.6 is the default version, but it is possible
  to set a 1.5.x version if required.
- JRuby version can be controlled at both project and task level. If no
  version is specified at either level, the maximum of default the JRuby
  version that AsciidoctorJ depends on and a coded minimum safe version
  of JRuby, will be used.
- AsciidoctorJExtension maintains it's own detached configuration which
  can be fine turned via resolution strategies for edge cases.
- the `org.asciidoctor.jvm.base` plugin adds a dependency report
  specifically for the detached configuration.
- GroovyDSL extensions are now registered eitehr on the project extension
  or the task extensions. The extensions are only loaded within a worker
  instance. The asciidoctor task is unloaded at the end of the worker and
  with it the extensions. (asciidoctor#166)
- AsciidoctorTask differentitates between top-level sources, secondary
  sources and resources in order to have a better idea of being
  out-of-date. (asciidoctor#185)
- It is possible to control whether resources should be copied or not. This
  allows a build to better deal with a backend such as PDF, which do not
  need resources to be copied.
- It is possible to perform the conversion from an intermediate working
  directory, which allows for a source directory to be kept pristine from
  intermediate artifacts generated from extensions such as ditaa.
- Using a worker approach for running Asciidoctor instances. (asciidoctor#220)
- Asciidoctor tasks can be configured to run AsciidoctorJ conversions in
  or out of process. Even when running in process AsciidoctorJ will be on
  an isolated classpath.
- Tasks support parallel mode which will run each backend (or in the case
  of Epub, each output format) in a separate worker. This behevaiour can
  be turned off in which case only one Asciidoctor instance is used to run
  all conversions in sequence.
- For cases where Gradle's idea of supplementing the classpath for workers
  do fail, there is a special `inProcess = JAVA_EXEC` that will run the
  conversion out of process, albeit less efficient than an out-of-process
  worker.
- Due to Gradle API classpath leakage, builds with Gradle 4.0-4.2 will
  always run in `JAVA_EXEC` mode to prevent issues.
- `AsciidoctorJPdf` plugin has been added which adds a single
  `asciidoctorPdf` task and configures it accordingly to PDF behaviour.
  It also sets a default version of the `asciidoctorj-pdf` dependency.
- If the PDF backend is used and the JRuby version starts with '9.x'
  then place SnakeYaml v1.13 on the classpath.
- Backends and separateOutputDirs are configured via an outputOptions
  closure or action.
- `AsciidoctorJEpub` plugin has been added which adds a single
  `asciidoctorEpub` task and configures it accordingly to EPUB behaviour.
  It also sets a default version of the `asciidoctorj-epub` dependency.
- Epub output formats can be set via the `ebookFormats` method.
- Additional Kindlegen plugin which is invoked by EPUB for when the format
  is KF8. The plugin will bootstrap kindlegen on all supported platforms.
- Work around gradle/gradle#3698 and Xerces API
  clash by running EPub conversions using `inProcess = JAVA_EXEC`.
- All methods on the new task classes that take closures as parameters now
  also have equivalent Action parameters (asciidoctor#236).
- All new tasks are supportd by integration tests and compatibility tests. (asciidoctor#180)
- Various tests use a combination of JRuby & AsciidoctorJ versions to test
  compatibility at the integration test level.

Known issues:
- Intermittent failures in tests related to bad file descriptor. Could be
  similar to asciidoctor/asciidoctorj#442.
- EPUB3 + KF8 in one task (PendingFeature). Both formats in one task is
  currently failing. The exact failure message depends on which order
  (KF8+EPUB3 or EPUB3+KF8) the conversion takes place in.
- KF8 conversions fails under Windows.
  Related to asciidoctor/asciidoctorj#659 & jruby/jruby#4943.
- Does not work with JDK9 (but does with JDK10).

Backwards compatibility and migration:
- Legacy code moved to 'org.asciidoctor.gradle.compat' package,
  but get AsciidoctorTask in same package for compatibility purpose.
- Renamed AsciidoctorPlugin to AsciidoctorCompatibilityPlugin.
- Legacy plugin cannot be used with other Asciidoctor plugins within
  the same project.
- Existing 1.5.x deprecated methods has been removed from legacy
  AsciidoctorTask.

General:
- The version series is 2.0.0. It will be kept as alpha releases for
  a while.
- Project restructured into multiple plugins using 'base' plugin model
  for Asciidoctor plugins.
- Only support Gradle 4.0+.
- Only support JDK8+.
- For Gradle 4.5+ migration messages are controlled via `--warning-mode`.
- For Gradle 4.0-4.4 migration messages are controlled via `--info`.
- Additional text will be displayed on Gradle Plugin Portal for during
  alpha & beta releases.
- Compatibility testing has been added and initialy against Gradle
  versions 4.0.2, 4.3.1 & 4.6. (For JDK10 only test against 4.7).
- Some integration tests contain JRuby compatibility tests. Current test
  set is 1.7.27, 9.0.50, 9.1.17.0, 9.2.0.0.
- JDK compatibility testing are done from JDK8 -> JDK10 (Travis)
- Codenarc settings has been updated to find configuration from within
  subprojects.
- Updated license headers to include 2018.
- Integration tests utilises an offline Ivy repository (via Ivypot plugin)
  to reduce bandwith usage and test time.
- AsciidoctorJ, GroovyDSL etc. versions are defined in code and read by the
  build script. This provides one point of definition and ensure that code
  can have appropriate default versions.
- Test versions of JRuby and AsciidoctorJ is controlled via test fixtures.
- Renamed AsciidoctorPlugin to AsciidoctorCompatiblityPlugin
- Provide ability to either use AsciidoctorJ or AsciidoctorJS as the
  engine. (In this commit only AsciidoctorJ is implemented).

New generation AsciidoctorJ plugins and tasks:
- New (JVM) AsciidoctorJ extension can be added to both project & tasks.
  Extension in task can be used to override global settings from the
  project extension. It takes into account some of the ideas @manuelprinz
  had for asciidoctor#231 for is much more extensive.
- Extension has support for Asciidoctor verbose mode (asciidoctor#233).
  If `verboseMode` is set then a temporary file will be created and made
  part of Asciidoctor `requires`.
- AsciidoctorJ v1.6.0-alpha.6 is the default version, but it is possible
  to set a 1.5.x version if required.
- JRuby version can be controlled at both project and task level. If no
  version is specified at either level, the maximum of default the JRuby
  version that AsciidoctorJ depends on and a coded minimum safe version
  of JRuby, will be used.
- AsciidoctorJExtension maintains it's own detached configuration which
  can be fine turned via resolution strategies for edge cases.
- the `org.asciidoctor.jvm.base` plugin adds a dependency report
  specifically for the detached configuration.
- GroovyDSL extensions are now registered eitehr on the project extension
  or the task extensions. The extensions are only loaded within a worker
  instance. The asciidoctor task is unloaded at the end of the worker and
  with it the extensions. (asciidoctor#166)
- AsciidoctorTask differentitates between top-level sources, secondary
  sources and resources in order to have a better idea of being
  out-of-date. (asciidoctor#185)
- It is possible to control whether resources should be copied or not. This
  allows a build to better deal with a backend such as PDF, which do not
  need resources to be copied.
- It is possible to perform the conversion from an intermediate working
  directory, which allows for a source directory to be kept pristine from
  intermediate artifacts generated from extensions such as ditaa.
- Using a worker approach for running Asciidoctor instances. (asciidoctor#220)
- Asciidoctor tasks can be configured to run AsciidoctorJ conversions in
  or out of process. Even when running in process AsciidoctorJ will be on
  an isolated classpath.
- Tasks support parallel mode which will run each backend (or in the case
  of Epub, each output format) in a separate worker. This behevaiour can
  be turned off in which case only one Asciidoctor instance is used to run
  all conversions in sequence.
- For cases where Gradle's idea of supplementing the classpath for workers
  do fail, there is a special `inProcess = JAVA_EXEC` that will run the
  conversion out of process, albeit less efficient than an out-of-process
  worker.
- Due to Gradle API classpath leakage, builds with Gradle 4.0-4.2 will
  always run in `JAVA_EXEC` mode to prevent issues.
- `AsciidoctorJPdf` plugin has been added which adds a single
  `asciidoctorPdf` task and configures it accordingly to PDF behaviour.
  It also sets a default version of the `asciidoctorj-pdf` dependency.
- If the PDF backend is used and the JRuby version starts with '9.x'
  then place SnakeYaml v1.13 on the classpath.
- Backends and separateOutputDirs are configured via an outputOptions
  closure or action.
- `AsciidoctorJEpub` plugin has been added which adds a single
  `asciidoctorEpub` task and configures it accordingly to EPUB behaviour.
  It also sets a default version of the `asciidoctorj-epub` dependency.
- Epub output formats can be set via the `ebookFormats` method.
- Additional Kindlegen plugin which is invoked by EPUB for when the format
  is KF8. The plugin will bootstrap kindlegen on all supported platforms.
- Work around gradle/gradle#3698 and Xerces API
  clash by running EPub conversions using `inProcess = JAVA_EXEC`. Also
  depend on `groovy-all` dependency rather than `localGroovy()` to see if
  that provides relief for the issue.
- All methods on the new task classes that take closures as parameters now
  also have equivalent Action parameters (asciidoctor#236).
- All new tasks are supportd by integration tests and compatibility tests. (asciidoctor#180)
- Various tests use a combination of JRuby & AsciidoctorJ versions to test
  compatibility at the integration test level.

Known issues:
- Intermittent failures in tests related to bad file descriptor. Could be
  similar to asciidoctor/asciidoctorj#442.
- EPUB3 + KF8 in one task (PendingFeature). Both formats in one task is
  currently failing. The exact failure message depends on which order
  (KF8+EPUB3 or EPUB3+KF8) the conversion takes place in.
- KF8 conversions fails under Windows.
  Related to asciidoctor/asciidoctorj#659 & jruby/jruby#4943.
- Does not work with JDK9 (but does with JDK10).

Backwards compatibility and migration:
- Legacy code moved to 'org.asciidoctor.gradle.compat' package,
  but get AsciidoctorTask in same package for compatibility purpose.
- Renamed AsciidoctorPlugin to AsciidoctorCompatibilityPlugin.
- Legacy plugin cannot be used with other Asciidoctor plugins within
  the same project.
- Existing 1.5.x deprecated methods has been removed from legacy
  AsciidoctorTask.

General:
- The version series is 2.0.0. It will be kept as alpha releases for
  a while.
- Project restructured into multiple plugins using 'base' plugin model
  for Asciidoctor plugins.
- Only support Gradle 4.0+.
- Only support JDK8+.
- For Gradle 4.5+ migration messages are controlled via `--warning-mode`.
- For Gradle 4.0-4.4 migration messages are controlled via `--info`.
- Additional text will be displayed on Gradle Plugin Portal for during
  alpha & beta releases.
- Compatibility testing has been added and initialy against Gradle
  versions 4.0.2, 4.3.1 & 4.6. (For JDK10 only test against 4.7).
- Some integration tests contain JRuby compatibility tests. Current test
  set is 1.7.27, 9.0.50, 9.1.17.0, 9.2.0.0.
- JDK compatibility testing are done from JDK8 -> JDK10 (Travis)
- Codenarc settings has been updated to find configuration from within
  subprojects.
- Updated license headers to include 2018.
- Integration tests utilises an offline Ivy repository (via Ivypot plugin)
  to reduce bandwith usage and test time.
- AsciidoctorJ, GroovyDSL etc. versions are defined in code and read by the
  build script. This provides one point of definition and ensure that code
  can have appropriate default versions.
- Test versions of JRuby and AsciidoctorJ is controlled via test fixtures.
- Renamed AsciidoctorPlugin to AsciidoctorCompatiblityPlugin
- Provide ability to either use AsciidoctorJ or AsciidoctorJS as the
  engine. (In this commit only AsciidoctorJ is implemented).

New generation AsciidoctorJ plugins and tasks:
- New (JVM) AsciidoctorJ extension can be added to both project & tasks.
  Extension in task can be used to override global settings from the
  project extension. It takes into account some of the ideas @manuelprinz
  had for asciidoctor#231 for is much more extensive.
- Extension has support for Asciidoctor verbose mode (asciidoctor#233).
  If `verboseMode` is set then a temporary file will be created and made
  part of Asciidoctor `requires`.
- AsciidoctorJ v1.6.0-alpha.6 is the default version, but it is possible
  to set a 1.5.x version if required.
- JRuby version can be controlled at both project and task level. If no
  version is specified at either level, the maximum of default the JRuby
  version that AsciidoctorJ depends on and a coded minimum safe version
  of JRuby, will be used.
- AsciidoctorJExtension maintains it's own detached configuration which
  can be fine turned via resolution strategies for edge cases.
- the `org.asciidoctor.jvm.base` plugin adds a dependency report
  specifically for the detached configuration.
- GroovyDSL extensions are now registered eitehr on the project extension
  or the task extensions. The extensions are only loaded within a worker
  instance. The asciidoctor task is unloaded at the end of the worker and
  with it the extensions. (asciidoctor#166)
- AsciidoctorTask differentitates between top-level sources, secondary
  sources and resources in order to have a better idea of being
  out-of-date. (asciidoctor#185)
- It is possible to control whether resources should be copied or not. This
  allows a build to better deal with a backend such as PDF, which do not
  need resources to be copied.
- It is possible to perform the conversion from an intermediate working
  directory, which allows for a source directory to be kept pristine from
  intermediate artifacts generated from extensions such as ditaa.
- Using a worker approach for running Asciidoctor instances. (asciidoctor#220)
- Asciidoctor tasks can be configured to run AsciidoctorJ conversions in
  or out of process. Even when running in process AsciidoctorJ will be on
  an isolated classpath.
- Tasks support parallel mode which will run each backend (or in the case
  of Epub, each output format) in a separate worker. This behevaiour can
  be turned off in which case only one Asciidoctor instance is used to run
  all conversions in sequence.
- For cases where Gradle's idea of supplementing the classpath for workers
  do fail, there is a special `inProcess = JAVA_EXEC` that will run the
  conversion out of process, albeit less efficient than an out-of-process
  worker.
- Due to Gradle API classpath leakage, builds with Gradle 4.0-4.2 will
  always run in `JAVA_EXEC` mode to prevent issues.
- `AsciidoctorJPdf` plugin has been added which adds a single
  `asciidoctorPdf` task and configures it accordingly to PDF behaviour.
  It also sets a default version of the `asciidoctorj-pdf` dependency.
- If the PDF backend is used and the JRuby version starts with '9.x'
  then place SnakeYaml v1.13 on the classpath.
- Backends and separateOutputDirs are configured via an outputOptions
  closure or action.
- `AsciidoctorJEpub` plugin has been added which adds a single
  `asciidoctorEpub` task and configures it accordingly to EPUB behaviour.
  It also sets a default version of the `asciidoctorj-epub` dependency.
- Epub output formats can be set via the `ebookFormats` method.
- Additional Kindlegen plugin which is invoked by EPUB for when the format
  is KF8. The plugin will bootstrap kindlegen on all supported platforms.
- Work around gradle/gradle#3698 and Xerces API
  clash by running EPub conversions using `inProcess = JAVA_EXEC`. Also
  depend on `groovy-all` dependency rather than `localGroovy()` to see if
  that provides relief for the issue.
- All methods on the new task classes that take closures as parameters now
  also have equivalent Action parameters (asciidoctor#236).
- All new tasks are supportd by integration tests and compatibility tests. (asciidoctor#180)
- Various tests use a combination of JRuby & AsciidoctorJ versions to test
  compatibility at the integration test level.

Known issues:
- Intermittent failures in tests related to bad file descriptor. Could be
  similar to asciidoctor/asciidoctorj#442.
- EPUB3 + KF8 in one task (PendingFeature). Both formats in one task is
  currently failing. The exact failure message depends on which order
  (KF8+EPUB3 or EPUB3+KF8) the conversion takes place in.
- KF8 conversions fails under Windows.
  Related to asciidoctor/asciidoctorj#659 & jruby/jruby#4943.
- Does not work with JDK9 (but does with JDK10).

Backwards compatibility and migration:
- Legacy code moved to 'org.asciidoctor.gradle.compat' package,
  but get AsciidoctorTask in same package for compatibility purpose.
- Renamed AsciidoctorPlugin to AsciidoctorCompatibilityPlugin.
- Legacy plugin cannot be used with other Asciidoctor plugins within
  the same project.
- Existing 1.5.x deprecated methods has been removed from legacy
  AsciidoctorTask.

General:
- The version series is 2.0.0. It will be kept as alpha releases for
  a while.
- Project restructured into multiple plugins using 'base' plugin model
  for Asciidoctor plugins.
- Only support Gradle 4.0+.
- Only support JDK8+.
- For Gradle 4.5+ migration messages are controlled via `--warning-mode`.
- For Gradle 4.0-4.4 migration messages are controlled via `--info`.
- Additional text will be displayed on Gradle Plugin Portal for during
  alpha & beta releases.
- Compatibility testing has been added and initialy against Gradle
  versions 4.0.2, 4.3.1 & 4.6. (For JDK10 only test against 4.7).
- Some integration tests contain JRuby compatibility tests. Current test
  set is 1.7.27, 9.0.50, 9.1.17.0, 9.2.0.0.
- JDK compatibility testing are done from JDK8 -> JDK10 (Travis)
- Codenarc settings has been updated to find configuration from within
  subprojects.
- Updated license headers to include 2018.
- Integration tests utilises an offline Ivy repository (via Ivypot plugin)
  to reduce bandwith usage and test time.
- AsciidoctorJ, GroovyDSL etc. versions are defined in code and read by the
  build script. This provides one point of definition and ensure that code
  can have appropriate default versions.
- Test versions of JRuby and AsciidoctorJ is controlled via test fixtures.
- Renamed AsciidoctorPlugin to AsciidoctorCompatiblityPlugin
- Provide ability to either use AsciidoctorJ or AsciidoctorJS as the
  engine. (In this commit only AsciidoctorJ is implemented).

New generation AsciidoctorJ plugins and tasks:
- New (JVM) AsciidoctorJ extension can be added to both project & tasks.
  Extension in task can be used to override global settings from the
  project extension. It takes into account some of the ideas @manuelprinz
  had for asciidoctor#231 for is much more extensive.
- Extension has support for Asciidoctor verbose mode (asciidoctor#233).
  If `verboseMode` is set then a temporary file will be created and made
  part of Asciidoctor `requires`.
- AsciidoctorJ v1.6.0-alpha.6 is the default version, but it is possible
  to set a 1.5.x version if required.
- JRuby version can be controlled at both project and task level. If no
  version is specified at either level, the maximum of default the JRuby
  version that AsciidoctorJ depends on and a coded minimum safe version
  of JRuby, will be used.
- AsciidoctorJExtension maintains it's own detached configuration which
  can be fine turned via resolution strategies for edge cases.
- the `org.asciidoctor.jvm.base` plugin adds a dependency report
  specifically for the detached configuration.
- GroovyDSL extensions are now registered eitehr on the project extension
  or the task extensions. The extensions are only loaded within a worker
  instance. The asciidoctor task is unloaded at the end of the worker and
  with it the extensions. (asciidoctor#166)
- AsciidoctorTask differentitates between top-level sources, secondary
  sources and resources in order to have a better idea of being
  out-of-date. (asciidoctor#185)
- It is possible to control whether resources should be copied or not. This
  allows a build to better deal with a backend such as PDF, which do not
  need resources to be copied.
- It is possible to perform the conversion from an intermediate working
  directory, which allows for a source directory to be kept pristine from
  intermediate artifacts generated from extensions such as ditaa.
- Using a worker approach for running Asciidoctor instances. (asciidoctor#220)
- Asciidoctor tasks can be configured to run AsciidoctorJ conversions in
  or out of process. Even when running in process AsciidoctorJ will be on
  an isolated classpath.
- Tasks support parallel mode which will run each backend (or in the case
  of Epub, each output format) in a separate worker. This behevaiour can
  be turned off in which case only one Asciidoctor instance is used to run
  all conversions in sequence.
- For cases where Gradle's idea of supplementing the classpath for workers
  do fail, there is a special `inProcess = JAVA_EXEC` that will run the
  conversion out of process, albeit less efficient than an out-of-process
  worker.
- Due to Gradle API classpath leakage, builds with Gradle 4.0-4.2 will
  always run in `JAVA_EXEC` mode to prevent issues.
- `AsciidoctorJPdf` plugin has been added which adds a single
  `asciidoctorPdf` task and configures it accordingly to PDF behaviour.
  It also sets a default version of the `asciidoctorj-pdf` dependency.
- If the PDF backend is used and the JRuby version starts with '9.x'
  then place SnakeYaml v1.13 on the classpath.
- Backends and separateOutputDirs are configured via an outputOptions
  closure or action.
- `AsciidoctorJEpub` plugin has been added which adds a single
  `asciidoctorEpub` task and configures it accordingly to EPUB behaviour.
  It also sets a default version of the `asciidoctorj-epub` dependency.
- Epub output formats can be set via the `ebookFormats` method.
- Additional Kindlegen plugin which is invoked by EPUB for when the format
  is KF8. The plugin will bootstrap kindlegen on all supported platforms.
- Work around gradle/gradle#3698 and Xerces API
  clash by running EPub conversions using `inProcess = JAVA_EXEC`. Also
  depend on `groovy-all` dependency rather than `localGroovy()` to see if
  that provides relief for the issue.
- All methods on the new task classes that take closures as parameters now
  also have equivalent Action parameters (asciidoctor#236).
- All new tasks are supportd by integration tests and compatibility tests. (asciidoctor#180)
- Various tests use a combination of JRuby & AsciidoctorJ versions to test
  compatibility at the integration test level.

Known issues:
- Intermittent failures in tests related to bad file descriptor. Could be
  similar to asciidoctor/asciidoctorj#442.
- EPUB3 + KF8 in one task (PendingFeature). Both formats in one task is
  currently failing. The exact failure message depends on which order
  (KF8+EPUB3 or EPUB3+KF8) the conversion takes place in.
- KF8 conversions fails under Windows.
  Related to asciidoctor/asciidoctorj#659 & jruby/jruby#4943.
- Does not work with JDK9 (but does with JDK10).

Backwards compatibility and migration:
- Legacy code moved to 'org.asciidoctor.gradle.compat' package,
  but get AsciidoctorTask in same package for compatibility purpose.
- Renamed AsciidoctorPlugin to AsciidoctorCompatibilityPlugin.
- Legacy plugin cannot be used with other Asciidoctor plugins within
  the same project.
- Existing 1.5.x deprecated methods has been removed from legacy
  AsciidoctorTask.

General:
- The version series is 2.0.0. It will be kept as alpha releases for
  a while.
- Project restructured into multiple plugins using 'base' plugin model
  for Asciidoctor plugins.
- Only support Gradle 4.0+.
- Only support JDK8+.
- For Gradle 4.5+ migration messages are controlled via `--warning-mode`.
- For Gradle 4.0-4.4 migration messages are controlled via `--info`.
- Additional text will be displayed on Gradle Plugin Portal for during
  alpha & beta releases.
- Compatibility testing has been added and initialy against Gradle
  versions 4.0.2, 4.3.1 & 4.6. (For JDK10 only test against 4.7).
- Some integration tests contain JRuby compatibility tests. Current test
  set is 1.7.27, 9.0.5.0, 9.1.17.0, 9.2.0.0.
- JDK compatibility testing are done from JDK8 -> JDK10 (Travis)
- Codenarc settings has been updated to find configuration from within
  subprojects.
- Updated license headers to include 2018.
- Integration tests utilises an offline Ivy repository (via Ivypot plugin)
  to reduce bandwith usage and test time.
- AsciidoctorJ, GroovyDSL etc. versions are defined in code and read by the
  build script. This provides one point of definition and ensure that code
  can have appropriate default versions.
- Test versions of JRuby and AsciidoctorJ is controlled via test fixtures.
- Renamed AsciidoctorPlugin to AsciidoctorCompatiblityPlugin
- Provide ability to either use AsciidoctorJ or AsciidoctorJS as the
  engine. (In this commit only AsciidoctorJ is implemented).
- Test result loged in real-time when running on Appveyor.

New generation AsciidoctorJ plugins and tasks:
- New (JVM) AsciidoctorJ extension can be added to both project & tasks.
  Extension in task can be used to override global settings from the
  project extension. It takes into account some of the ideas @manuelprinz
  had for asciidoctor#231 for is much more extensive.
- Extension has support for Asciidoctor verbose mode (asciidoctor#233).
  If `verboseMode` is set then a temporary file will be created and made
  part of Asciidoctor `requires`.
- AsciidoctorJ v1.6.0-alpha.6 is the default version, but it is possible
  to set a 1.5.x version if required.
- JRuby version can be controlled at both project and task level. If no
  version is specified at either level, the maximum of default the JRuby
  version that AsciidoctorJ depends on and a coded minimum safe version
  of JRuby, will be used.
- AsciidoctorJExtension maintains it's own detached configuration which
  can be fine turned via resolution strategies for edge cases.
- the `org.asciidoctor.jvm.base` plugin adds a dependency report
  specifically for the detached configuration.
- GroovyDSL extensions are now registered eitehr on the project extension
  or the task extensions. The extensions are only loaded within a worker
  instance. The asciidoctor task is unloaded at the end of the worker and
  with it the extensions. (asciidoctor#166)
- AsciidoctorTask differentitates between top-level sources, secondary
  sources and resources in order to have a better idea of being
  out-of-date. (asciidoctor#185)
- It is possible to control whether resources should be copied or not. This
  allows a build to better deal with a backend such as PDF, which do not
  need resources to be copied.
- It is possible to perform the conversion from an intermediate working
  directory, which allows for a source directory to be kept pristine from
  intermediate artifacts generated from extensions such as ditaa.
- Using a worker approach for running Asciidoctor instances. (asciidoctor#220)
- Asciidoctor tasks can be configured to run AsciidoctorJ conversions in
  or out of process. Even when running in process AsciidoctorJ will be on
  an isolated classpath.
- Tasks support parallel mode which will run each backend (or in the case
  of Epub, each output format) in a separate worker. This behevaiour can
  be turned off in which case only one Asciidoctor instance is used to run
  all conversions in sequence.
- For cases where Gradle's idea of supplementing the classpath for workers
  do fail, there is a special `inProcess = JAVA_EXEC` that will run the
  conversion out of process, albeit less efficient than an out-of-process
  worker.
- Due to Gradle API classpath leakage, builds with Gradle 4.0-4.2 will
  always run in `JAVA_EXEC` mode to prevent issues.
- `AsciidoctorJPdf` plugin has been added which adds a single
  `asciidoctorPdf` task and configures it accordingly to PDF behaviour.
  It also sets a default version of the `asciidoctorj-pdf` dependency.
- If the PDF backend is used and the JRuby version starts with '9.x'
  then place SnakeYaml v1.13 on the classpath.
- Backends and separateOutputDirs are configured via an outputOptions
  closure or action.
- `AsciidoctorJEpub` plugin has been added which adds a single
  `asciidoctorEpub` task and configures it accordingly to EPUB behaviour.
  It also sets a default version of the `asciidoctorj-epub` dependency.
- Epub output formats can be set via the `ebookFormats` method.
- Additional Kindlegen plugin which is invoked by EPUB for when the format
  is KF8. The plugin will bootstrap kindlegen on all supported platforms.
- Work around gradle/gradle#3698 and Xerces API
  clash by running EPub conversions using `inProcess = JAVA_EXEC`. Also
  depend on `groovy-all` dependency rather than `localGroovy()` to see if
  that provides relief for the issue.
- All methods on the new task classes that take closures as parameters now
  also have equivalent Action parameters (asciidoctor#236).
- All new tasks are supportd by integration tests and compatibility tests. (asciidoctor#180)
- Various tests use a combination of JRuby & AsciidoctorJ versions to test
  compatibility at the integration test level.

Known issues:
- Intermittent failures in tests related to bad file descriptor. Could be
  similar to asciidoctor/asciidoctorj#442.
- EPUB3 + KF8 in one task (PendingFeature). Both formats in one task is
  currently failing. The exact failure message depends on which order
  (KF8+EPUB3 or EPUB3+KF8) the conversion takes place in.
- KF8 conversions fails under Windows.
  Related to asciidoctor/asciidoctorj#659 & jruby/jruby#4943.
- Does not work with JDK9 (but does with JDK10).

Backwards compatibility and migration:
- Legacy code moved to 'org.asciidoctor.gradle.compat' package,
  but get AsciidoctorTask in same package for compatibility purpose.
- Renamed AsciidoctorPlugin to AsciidoctorCompatibilityPlugin.
- Legacy plugin cannot be used with other Asciidoctor plugins within
  the same project.
- Existing 1.5.x deprecated methods has been removed from legacy
  AsciidoctorTask.

General:
- The version series is 2.0.0. It will be kept as alpha releases for
  a while.
- Project restructured into multiple plugins using 'base' plugin model
  for Asciidoctor plugins.
- Only support Gradle 4.0+.
- Only support JDK8+.
- For Gradle 4.5+ migration messages are controlled via `--warning-mode`.
- For Gradle 4.0-4.4 migration messages are controlled via `--info`.
- Additional text will be displayed on Gradle Plugin Portal for during
  alpha & beta releases.
- Compatibility testing has been added and initialy against Gradle
  versions 4.0.2, 4.3.1 & 4.6. (For JDK10 only test against 4.7).
- Some integration tests contain JRuby compatibility tests. Current test
  set is 1.7.27, 9.0.5.0, 9.1.17.0, 9.2.0.0.
- JDK compatibility testing are done from JDK8 -> JDK10 (Travis)
- Codenarc settings has been updated to find configuration from within
  subprojects.
- Updated license headers to include 2018.
- Integration tests utilises an offline Ivy repository (via Ivypot plugin)
  to reduce bandwith usage and test time.
- AsciidoctorJ, GroovyDSL etc. versions are defined in code and read by the
  build script. This provides one point of definition and ensure that code
  can have appropriate default versions.
- Test versions of JRuby and AsciidoctorJ is controlled via test fixtures.
- Renamed AsciidoctorPlugin to AsciidoctorCompatiblityPlugin
- Provide ability to either use AsciidoctorJ or AsciidoctorJS as the
  engine. (In this commit only AsciidoctorJ is implemented).
- Test result loged in real-time when running on Appveyor.

New generation AsciidoctorJ plugins and tasks:
- New (JVM) AsciidoctorJ extension can be added to both project & tasks.
  Extension in task can be used to override global settings from the
  project extension. It takes into account some of the ideas @manuelprinz
  had for asciidoctor#231 for is much more extensive.
- Extension has support for Asciidoctor verbose mode (asciidoctor#233).
  If `verboseMode` is set then a temporary file will be created and made
  part of Asciidoctor `requires`.
- AsciidoctorJ v1.6.0-alpha.6 is the default version, but it is possible
  to set a 1.5.x version if required.
- JRuby version can be controlled at both project and task level. If no
  version is specified at either level, the maximum of default the JRuby
  version that AsciidoctorJ depends on and a coded minimum safe version
  of JRuby, will be used.
- AsciidoctorJExtension maintains it's own detached configuration which
  can be fine turned via resolution strategies for edge cases.
- the `org.asciidoctor.jvm.base` plugin adds a dependency report
  specifically for the detached configuration.
- GroovyDSL extensions are now registered eitehr on the project extension
  or the task extensions. The extensions are only loaded within a worker
  instance. The asciidoctor task is unloaded at the end of the worker and
  with it the extensions. (asciidoctor#166)
- AsciidoctorTask differentitates between top-level sources, secondary
  sources and resources in order to have a better idea of being
  out-of-date. (asciidoctor#185)
- It is possible to control whether resources should be copied or not. This
  allows a build to better deal with a backend such as PDF, which do not
  need resources to be copied.
- It is possible to perform the conversion from an intermediate working
  directory, which allows for a source directory to be kept pristine from
  intermediate artifacts generated from extensions such as ditaa.
- Using a worker approach for running Asciidoctor instances. (asciidoctor#220)
- Asciidoctor tasks can be configured to run AsciidoctorJ conversions in
  or out of process. Even when running in process AsciidoctorJ will be on
  an isolated classpath.
- Tasks support parallel mode which will run each backend (or in the case
  of Epub, each output format) in a separate worker. This behevaiour can
  be turned off in which case only one Asciidoctor instance is used to run
  all conversions in sequence.
- For cases where Gradle's idea of supplementing the classpath for workers
  do fail, there is a special `inProcess = JAVA_EXEC` that will run the
  conversion out of process, albeit less efficient than an out-of-process
  worker.
- Due to Gradle API classpath leakage, builds with Gradle 4.0-4.2 will
  always run in `JAVA_EXEC` mode to prevent issues.
- `AsciidoctorJPdf` plugin has been added which adds a single
  `asciidoctorPdf` task and configures it accordingly to PDF behaviour.
  It also sets a default version of the `asciidoctorj-pdf` dependency.
- If the PDF backend is used and the JRuby version starts with '9.x'
  then place SnakeYaml v1.13 on the classpath.
- Backends and separateOutputDirs are configured via an outputOptions
  closure or action.
- `AsciidoctorJEpub` plugin has been added which adds a single
  `asciidoctorEpub` task and configures it accordingly to EPUB behaviour.
  It also sets a default version of the `asciidoctorj-epub` dependency.
- Epub output formats can be set via the `ebookFormats` method.
- Additional Kindlegen plugin which is invoked by EPUB for when the format
  is KF8. The plugin will bootstrap kindlegen on all supported platforms.
- Work around gradle/gradle#3698 and Xerces API
  clash by running EPub conversions using `inProcess = JAVA_EXEC`. Also
  depend on `groovy-all` dependency rather than `localGroovy()` to see if
  that provides relief for the issue.
- All methods on the new task classes that take closures as parameters now
  also have equivalent Action parameters (asciidoctor#236).
- All new tasks are supportd by integration tests and compatibility tests. (asciidoctor#180)
- Various tests use a combination of JRuby & AsciidoctorJ versions to test
  compatibility at the integration test level.

Known issues:
- Intermittent failures in tests related to bad file descriptor. Could be
  similar to asciidoctor/asciidoctorj#442.
- EPUB3 + KF8 in one task (PendingFeature). Both formats in one task is
  currently failing. The exact failure message depends on which order
  (KF8+EPUB3 or EPUB3+KF8) the conversion takes place in.
- KF8 conversions fails under Windows.
  Related to asciidoctor/asciidoctorj#659 & jruby/jruby#4943.
- Does not work with JDK9 (but does with JDK10).

Backwards compatibility and migration:
- Legacy code moved to 'org.asciidoctor.gradle.compat' package,
  but get AsciidoctorTask in same package for compatibility purpose.
- Renamed AsciidoctorPlugin to AsciidoctorCompatibilityPlugin.
- Legacy plugin cannot be used with other Asciidoctor plugins within
  the same project.
- Existing 1.5.x deprecated methods has been removed from legacy
  AsciidoctorTask.

General:
- The version series is 2.0.0. It will be kept as alpha releases for
  a while.
- Project restructured into multiple plugins using 'base' plugin model
  for Asciidoctor plugins.
- Only support Gradle 4.0+.
- Only support JDK8+.
- For Gradle 4.5+ migration messages are controlled via `--warning-mode`.
- For Gradle 4.0-4.4 migration messages are controlled via `--info`.
- Additional text will be displayed on Gradle Plugin Portal for during
  alpha & beta releases.
- Compatibility testing has been added and initialy against Gradle
  versions 4.0.2, 4.3.1 & 4.6. (For JDK10 only test against 4.7).
- Some integration tests contain JRuby compatibility tests. Current test
  set is 1.7.27, 9.0.5.0, 9.1.17.0, 9.2.0.0.
- JDK compatibility testing are done from JDK8 -> JDK10 (Travis)
- Codenarc settings has been updated to find configuration from within
  subprojects.
- Updated license headers to include 2018.
- Integration tests utilises an offline Ivy repository (via Ivypot plugin)
  to reduce bandwith usage and test time.
- AsciidoctorJ, GroovyDSL etc. versions are defined in code and read by the
  build script. This provides one point of definition and ensure that code
  can have appropriate default versions.
- Test versions of JRuby and AsciidoctorJ is controlled via test fixtures.
- Renamed AsciidoctorPlugin to AsciidoctorCompatiblityPlugin
- Provide ability to either use AsciidoctorJ or AsciidoctorJS as the
  engine. (In this commit only AsciidoctorJ is implemented).
- Test result logged in real-time when running on Appveyor.

New generation AsciidoctorJ plugins and tasks:
- New (JVM) AsciidoctorJ extension can be added to both project & tasks.
  Extension in task can be used to override global settings from the
  project extension. It takes into account some of the ideas @manuelprinz
  had for asciidoctor#231 for is much more extensive.
- Extension has support for Asciidoctor verbose mode (asciidoctor#233).
  If `verboseMode` is set then a temporary file will be created and made
  part of Asciidoctor `requires`.
- AsciidoctorJ v1.6.0-alpha.6 is the default version, but it is possible
  to set a 1.5.x version if required.
- JRuby version can be controlled at both project and task level. If no
  version is specified at either level, the maximum of default the JRuby
  version that AsciidoctorJ depends on and a coded minimum safe version
  of JRuby, will be used.
- AsciidoctorJExtension maintains it's own detached configuration which
  can be fine turned via resolution strategies for edge cases.
- the `org.asciidoctor.jvm.base` plugin adds a dependency report
  specifically for the detached configuration.
- GroovyDSL extensions are now registered eitehr on the project extension
  or the task extensions. The extensions are only loaded within a worker
  instance. The asciidoctor task is unloaded at the end of the worker and
  with it the extensions. (asciidoctor#166)
- AsciidoctorTask differentitates between top-level sources, secondary
  sources and resources in order to have a better idea of being
  out-of-date. (asciidoctor#185)
- It is possible to control whether resources should be copied or not. This
  allows a build to better deal with a backend such as PDF, which do not
  need resources to be copied.
- It is possible to perform the conversion from an intermediate working
  directory, which allows for a source directory to be kept pristine from
  intermediate artifacts generated from extensions such as ditaa.
- Using a worker approach for running Asciidoctor instances. (asciidoctor#220)
- Asciidoctor tasks can be configured to run AsciidoctorJ conversions in
  or out of process. Even when running in process AsciidoctorJ will be on
  an isolated classpath.
- Tasks support parallel mode which will run each backend (or in the case
  of Epub, each output format) in a separate worker. This behevaiour can
  be turned off in which case only one Asciidoctor instance is used to run
  all conversions in sequence.
- For cases where Gradle's idea of supplementing the classpath for workers
  do fail, there is a special `inProcess = JAVA_EXEC` that will run the
  conversion out of process, albeit less efficient than an out-of-process
  worker.
- Due to Gradle API classpath leakage, builds with Gradle 4.0-4.2 will
  always run in `JAVA_EXEC` mode to prevent issues.
- `AsciidoctorJPdf` plugin has been added which adds a single
  `asciidoctorPdf` task and configures it accordingly to PDF behaviour.
  It also sets a default version of the `asciidoctorj-pdf` dependency.
- If the PDF backend is used and the JRuby version starts with '9.x'
  then place SnakeYaml v1.13 on the classpath.
- Backends and separateOutputDirs are configured via an outputOptions
  closure or action.
- `AsciidoctorJEpub` plugin has been added which adds a single
  `asciidoctorEpub` task and configures it accordingly to EPUB behaviour.
  It also sets a default version of the `asciidoctorj-epub` dependency.
- Epub output formats can be set via the `ebookFormats` method.
- Additional Kindlegen plugin which is invoked by EPUB for when the format
  is KF8. The plugin will bootstrap kindlegen on all supported platforms.
- Work around gradle/gradle#3698 and Xerces API
  clash by running EPub conversions using `inProcess = JAVA_EXEC`. Also
  depend on `groovy-all` dependency rather than `localGroovy()` to see if
  that provides relief for the issue.
- All methods on the new task classes that take closures as parameters now
  also have equivalent Action parameters (asciidoctor#236).
- All new tasks are supportd by integration tests and compatibility tests. (asciidoctor#180)
- Various tests use a combination of JRuby & AsciidoctorJ versions to test
  compatibility at the integration test level.

Known issues:
- Intermittent failures in tests related to bad file descriptor. Could be
  similar to asciidoctor/asciidoctorj#442.
- EPUB3 + KF8 in one task (PendingFeature). Both formats in one task is
  currently failing. The exact failure message depends on which order
  (KF8+EPUB3 or EPUB3+KF8) the conversion takes place in.
- KF8 conversions fails under Windows.
  Related to asciidoctor/asciidoctorj#659 & jruby/jruby#4943.
- Does not work with JDK9 (but does with JDK10).

Backwards compatibility and migration:
- Legacy code moved to 'org.asciidoctor.gradle.compat' package,
  but get AsciidoctorTask in same package for compatibility purpose.
- Renamed AsciidoctorPlugin to AsciidoctorCompatibilityPlugin.
- Legacy plugin cannot be used with other Asciidoctor plugins within
  the same project.
- Existing 1.5.x deprecated methods has been removed from legacy
  AsciidoctorTask.

General:
- The version series is 2.0.0. It will be kept as alpha releases for
  a while.
- Project restructured into multiple plugins using 'base' plugin model
  for Asciidoctor plugins.
- Only support Gradle 4.0+.
- Only support JDK8+.
- For Gradle 4.5+ migration messages are controlled via `--warning-mode`.
- For Gradle 4.0-4.4 migration messages are controlled via `--info`.
- Additional text will be displayed on Gradle Plugin Portal for during
  alpha & beta releases.
- Compatibility testing has been added and initialy against Gradle
  versions 4.0.2, 4.3.1 & 4.6. (For JDK10 only test against 4.7).
- Some integration tests contain JRuby compatibility tests. Current test
  set is 1.7.27, 9.0.5.0/9.1.0.0, 9.1.17.0, 9.2.0.0.
- JDK compatibility testing are done from JDK8 -> JDK10 (Travis)
- Codenarc settings has been updated to find configuration from within
  subprojects.
- Updated license headers to include 2018.
- Integration tests utilises an offline Ivy repository (via Ivypot plugin)
  to reduce bandwith usage and test time.
- AsciidoctorJ, GroovyDSL etc. versions are defined in code and read by the
  build script. This provides one point of definition and ensure that code
  can have appropriate default versions.
- Test versions of JRuby and AsciidoctorJ is controlled via test fixtures.
- Renamed AsciidoctorPlugin to AsciidoctorCompatiblityPlugin
- Provide ability to either use AsciidoctorJ or AsciidoctorJS as the
  engine. (In this commit only AsciidoctorJ is implemented).
- Test result logged in real-time when running on Appveyor.

New generation AsciidoctorJ plugins and tasks:
- New (JVM) AsciidoctorJ extension can be added to both project & tasks.
  Extension in task can be used to override global settings from the
  project extension. It takes into account some of the ideas @manuelprinz
  had for asciidoctor#231 for is much more extensive.
- Extension has support for Asciidoctor verbose mode (asciidoctor#233).
  If `verboseMode` is set then a temporary file will be created and made
  part of Asciidoctor `requires`.
- AsciidoctorJ v1.6.0-alpha.6 is the default version, but it is possible
  to set a 1.5.x version if required.
- JRuby version can be controlled at both project and task level. If no
  version is specified at either level, the maximum of default the JRuby
  version that AsciidoctorJ depends on and a coded minimum safe version
  of JRuby, will be used.
- AsciidoctorJExtension maintains it's own detached configuration which
  can be fine turned via resolution strategies for edge cases.
- the `org.asciidoctor.jvm.base` plugin adds a dependency report
  specifically for the detached configuration.
- GroovyDSL extensions are now registered eitehr on the project extension
  or the task extensions. The extensions are only loaded within a worker
  instance. The asciidoctor task is unloaded at the end of the worker and
  with it the extensions. (asciidoctor#166)
- AsciidoctorTask differentitates between top-level sources, secondary
  sources and resources in order to have a better idea of being
  out-of-date. (asciidoctor#185)
- It is possible to control whether resources should be copied or not. This
  allows a build to better deal with a backend such as PDF, which do not
  need resources to be copied.
- It is possible to perform the conversion from an intermediate working
  directory, which allows for a source directory to be kept pristine from
  intermediate artifacts generated from extensions such as ditaa.
- Using a worker approach for running Asciidoctor instances. (asciidoctor#220)
- Asciidoctor tasks can be configured to run AsciidoctorJ conversions in
  or out of process. Even when running in process AsciidoctorJ will be on
  an isolated classpath.
- Tasks support parallel mode which will run each backend (or in the case
  of Epub, each output format) in a separate worker. This behevaiour can
  be turned off in which case only one Asciidoctor instance is used to run
  all conversions in sequence.
- For cases where Gradle's idea of supplementing the classpath for workers
  do fail, there is a special `inProcess = JAVA_EXEC` that will run the
  conversion out of process, albeit less efficient than an out-of-process
  worker.
- Due to Gradle API classpath leakage, builds with Gradle 4.0-4.2 will
  always run in `JAVA_EXEC` mode to prevent issues.
- `AsciidoctorJPdf` plugin has been added which adds a single
  `asciidoctorPdf` task and configures it accordingly to PDF behaviour.
  It also sets a default version of the `asciidoctorj-pdf` dependency.
- If the PDF backend is used and the JRuby version starts with '9.x'
  then place SnakeYaml v1.13 on the classpath.
- Backends and separateOutputDirs are configured via an outputOptions
  closure or action.
- `AsciidoctorJEpub` plugin has been added which adds a single
  `asciidoctorEpub` task and configures it accordingly to EPUB behaviour.
  It also sets a default version of the `asciidoctorj-epub` dependency.
- Epub output formats can be set via the `ebookFormats` method.
- Additional Kindlegen plugin which is invoked by EPUB for when the format
  is KF8. The plugin will bootstrap kindlegen on all supported platforms.
- Work around gradle/gradle#3698 and Xerces API
  clash by running EPub conversions using `inProcess = JAVA_EXEC`. Also
  depend on `groovy-all` dependency rather than `localGroovy()` to see if
  that provides relief for the issue.
- All methods on the new task classes that take closures as parameters now
  also have equivalent Action parameters (asciidoctor#236).
- All new tasks are supportd by integration tests and compatibility tests. (asciidoctor#180)
- Various tests use a combination of JRuby & AsciidoctorJ versions to test
  compatibility at the integration test level.

Known issues:
- Intermittent failures in tests related to bad file descriptor. Could be
  similar to asciidoctor/asciidoctorj#442.
- EPUB3 + KF8 in one task (PendingFeature). Both formats in one task is
  currently failing. The exact failure message depends on which order
  (KF8+EPUB3 or EPUB3+KF8) the conversion takes place in.
- KF8 conversions fails under Windows.
  Related to asciidoctor/asciidoctorj#659 & jruby/jruby#4943.
- Does not work with JDK9 (but does with JDK10).

Backwards compatibility and migration:
- Legacy code moved to 'org.asciidoctor.gradle.compat' package,
  but get AsciidoctorTask in same package for compatibility purpose.
- Renamed AsciidoctorPlugin to AsciidoctorCompatibilityPlugin.
- Legacy plugin cannot be used with other Asciidoctor plugins within
  the same project.
- Existing 1.5.x deprecated methods has been removed from legacy
  AsciidoctorTask.

General:
- The version series is 2.0.0. It will be kept as alpha releases for
  a while.
- Project restructured into multiple plugins using 'base' plugin model
  for Asciidoctor plugins.
- Only support Gradle 4.0+.
- Only support JDK8+.
- For Gradle 4.5+ migration messages are controlled via `--warning-mode`.
- For Gradle 4.0-4.4 migration messages are controlled via `--info`.
- Additional text will be displayed on Gradle Plugin Portal for during
  alpha & beta releases.
- Compatibility testing has been added and initialy against Gradle
  versions 4.0.2, 4.3.1 & 4.6. (For JDK10 only test against 4.7).
- Some integration tests contain JRuby compatibility tests. Current test
  set is 1.7.27, 9.0.5.0/9.1.0.0, 9.1.17.0, 9.2.0.0.
- JDK compatibility testing are done from JDK8 -> JDK10 (Travis)
- Codenarc settings has been updated to find configuration from within
  subprojects.
- Updated license headers to include 2018.
- Integration tests utilises an offline Ivy repository (via Ivypot plugin)
  to reduce bandwith usage and test time.
- AsciidoctorJ, GroovyDSL etc. versions are defined in code and read by the
  build script. This provides one point of definition and ensure that code
  can have appropriate default versions.
- Test versions of JRuby and AsciidoctorJ is controlled via test fixtures.
- Renamed AsciidoctorPlugin to AsciidoctorCompatiblityPlugin
- Provide ability to either use AsciidoctorJ or AsciidoctorJS as the
  engine. (In this commit only AsciidoctorJ is implemented).
- Test result logged in real-time when running on Appveyor.

New generation AsciidoctorJ plugins and tasks:
- New (JVM) AsciidoctorJ extension can be added to both project & tasks.
  Extension in task can be used to override global settings from the
  project extension. It takes into account some of the ideas @manuelprinz
  had for asciidoctor#231 for is much more extensive.
- Extension has support for Asciidoctor verbose mode (asciidoctor#233).
  If `verboseMode` is set then a temporary file will be created and made
  part of Asciidoctor `requires`.
- AsciidoctorJ v1.6.0-alpha.6 is the default version, but it is possible
  to set a 1.5.x version if required.
- JRuby version can be controlled at both project and task level. If no
  version is specified at either level, the maximum of default the JRuby
  version that AsciidoctorJ depends on and a coded minimum safe version
  of JRuby, will be used.
- AsciidoctorJExtension maintains it's own detached configuration which
  can be fine turned via resolution strategies for edge cases.
- the `org.asciidoctor.jvm.base` plugin adds a dependency report
  specifically for the detached configuration.
- GroovyDSL extensions are now registered eitehr on the project extension
  or the task extensions. The extensions are only loaded within a worker
  instance. The asciidoctor task is unloaded at the end of the worker and
  with it the extensions. (asciidoctor#166)
- AsciidoctorTask differentitates between top-level sources, secondary
  sources and resources in order to have a better idea of being
  out-of-date. (asciidoctor#185)
- It is possible to control whether resources should be copied or not. This
  allows a build to better deal with a backend such as PDF, which do not
  need resources to be copied.
- It is possible to perform the conversion from an intermediate working
  directory, which allows for a source directory to be kept pristine from
  intermediate artifacts generated from extensions such as ditaa.
- Using a worker approach for running Asciidoctor instances. (asciidoctor#220)
- Asciidoctor tasks can be configured to run AsciidoctorJ conversions in
  or out of process. Even when running in process AsciidoctorJ will be on
  an isolated classpath.
- Tasks support parallel mode which will run each backend (or in the case
  of Epub, each output format) in a separate worker. This behevaiour can
  be turned off in which case only one Asciidoctor instance is used to run
  all conversions in sequence.
- For cases where Gradle's idea of supplementing the classpath for workers
  do fail, there is a special `inProcess = JAVA_EXEC` that will run the
  conversion out of process, albeit less efficient than an out-of-process
  worker.
- Due to Gradle API classpath leakage, builds with Gradle 4.0-4.2 will
  always run in `JAVA_EXEC` mode to prevent issues.
- `AsciidoctorJPdf` plugin has been added which adds a single
  `asciidoctorPdf` task and configures it accordingly to PDF behaviour.
  It also sets a default version of the `asciidoctorj-pdf` dependency.
- If the PDF backend is used and the JRuby version starts with '9.x'
  then place SnakeYaml v1.13 on the classpath.
- Backends and separateOutputDirs are configured via an outputOptions
  closure or action.
- `AsciidoctorJEpub` plugin has been added which adds a single
  `asciidoctorEpub` task and configures it accordingly to EPUB behaviour.
  It also sets a default version of the `asciidoctorj-epub` dependency.
- Epub output formats can be set via the `ebookFormats` method.
- Additional Kindlegen plugin which is invoked by EPUB for when the format
  is KF8. The plugin will bootstrap kindlegen on all supported platforms.
- Work around gradle/gradle#3698 and Xerces API
  clash by running EPub conversions using `inProcess = JAVA_EXEC`. Also
  depend on `groovy-all` dependency rather than `localGroovy()` to see if
  that provides relief for the issue.
- All methods on the new task classes that take closures as parameters now
  also have equivalent Action parameters (asciidoctor#236).
- All new tasks are supportd by integration tests and compatibility tests. (asciidoctor#180)
- Various tests use a combination of JRuby & AsciidoctorJ versions to test
  compatibility at the integration test level.

Known issues:
- Intermittent failures in tests related to bad file descriptor. Could be
  similar to asciidoctor/asciidoctorj#442.
- EPUB3 + KF8 in one task (PendingFeature). Both formats in one task is
  currently failing. The exact failure message depends on which order
  (KF8+EPUB3 or EPUB3+KF8) the conversion takes place in.
- KF8 conversions fails under Windows.
  Related to asciidoctor/asciidoctorj#659 & jruby/jruby#4943.
- Does not work with JDK9 (but does with JDK10).

Backwards compatibility and migration:
- Legacy code moved to 'org.asciidoctor.gradle.compat' package,
  but get AsciidoctorTask in same package for compatibility purpose.
- Renamed AsciidoctorPlugin to AsciidoctorCompatibilityPlugin.
- Legacy plugin cannot be used with other Asciidoctor plugins within
  the same project.
- Existing 1.5.x deprecated methods has been removed from legacy
  AsciidoctorTask.

General:
- The version series is 2.0.0. It will be kept as alpha releases for
  a while.
- Project restructured into multiple plugins using 'base' plugin model
  for Asciidoctor plugins.
- Only support Gradle 4.0+.
- Only support JDK8+.
- For Gradle 4.5+ migration messages are controlled via `--warning-mode`.
- For Gradle 4.0-4.4 migration messages are controlled via `--info`.
- Additional text will be displayed on Gradle Plugin Portal for during
  alpha & beta releases.
- Compatibility testing has been added and initialy against Gradle
  versions 4.0.2, 4.3.1 & 4.6. (For JDK10 only test against 4.7).
- Some integration tests contain JRuby compatibility tests. Current test
  set is 1.7.27, 9.0.5.0/9.1.0.0, 9.1.17.0, 9.2.0.0.
- JDK compatibility testing are done from JDK8 -> JDK10 (Travis)
- Codenarc settings has been updated to find configuration from within
  subprojects.
- Updated license headers to include 2018.
- Integration tests utilises an offline Ivy repository (via Ivypot plugin)
  to reduce bandwith usage and test time.
- AsciidoctorJ, GroovyDSL etc. versions are defined in code and read by the
  build script. This provides one point of definition and ensure that code
  can have appropriate default versions.
- Test versions of JRuby and AsciidoctorJ is controlled via test fixtures.
- Renamed AsciidoctorPlugin to AsciidoctorCompatiblityPlugin
- Provide ability to either use AsciidoctorJ or AsciidoctorJS as the
  engine. (In this commit only AsciidoctorJ is implemented).
- Test result logged in real-time when running on Appveyor.

New generation AsciidoctorJ plugins and tasks:
- New (JVM) AsciidoctorJ extension can be added to both project & tasks.
  Extension in task can be used to override global settings from the
  project extension. It takes into account some of the ideas @manuelprinz
  had for asciidoctor#231 for is much more extensive.
- Extension has support for Asciidoctor verbose mode (asciidoctor#233).
  If `verboseMode` is set then a temporary file will be created and made
  part of Asciidoctor `requires`.
- AsciidoctorJ v1.6.0-alpha.6 is the default version, but it is possible
  to set a 1.5.x version if required.
- JRuby version can be controlled at both project and task level. If no
  version is specified at either level, the maximum of default the JRuby
  version that AsciidoctorJ depends on and a coded minimum safe version
  of JRuby, will be used.
- AsciidoctorJExtension maintains it's own detached configuration which
  can be fine turned via resolution strategies for edge cases.
- the `org.asciidoctor.jvm.base` plugin adds a dependency report
  specifically for the detached configuration.
- GroovyDSL extensions are now registered either on the project extension
  or the task extensions. The extensions are only loaded within a worker
  instance. The asciidoctor task is unloaded at the end of the worker and
  with it the extensions. (asciidoctor#166)
- Defining etension inline with closures are no longer supported.
  (If someone can solve the dehydrate/rehydrate problem then it can be a
  feature again).
- AsciidoctorTask differentitates between top-level sources, secondary
  sources and resources in order to have a better idea of being
  out-of-date. (asciidoctor#185)
- It is possible to control whether resources should be copied or not. This
  allows a build to better deal with a backend such as PDF, which do not
  need resources to be copied.
- It is possible to perform the conversion from an intermediate working
  directory, which allows for a source directory to be kept pristine from
  intermediate artifacts generated from extensions such as ditaa.
- Using a worker approach for running Asciidoctor instances. (asciidoctor#220)
- Asciidoctor tasks can be configured to run AsciidoctorJ conversions in
  or out of process. Even when running in process AsciidoctorJ will be on
  an isolated classpath.
- Tasks support parallel mode which will run each backend (or in the case
  of Epub, each output format) in a separate worker. This behevaiour can
  be turned off in which case only one Asciidoctor instance is used to run
  all conversions in sequence.
- For cases where Gradle's idea of supplementing the classpath for workers
  do fail, there is a special `inProcess = JAVA_EXEC` that will run the
  conversion out of process, albeit less efficient than an out-of-process
  worker.
- Due to Gradle API classpath leakage, builds with Gradle 4.0-4.2 will
  always run in `JAVA_EXEC` mode to prevent issues.
- `AsciidoctorJPdf` plugin has been added which adds a single
  `asciidoctorPdf` task and configures it accordingly to PDF behaviour.
  It also sets a default version of the `asciidoctorj-pdf` dependency.
- If the PDF backend is used and the JRuby version starts with '9.x'
  then place SnakeYaml v1.13 on the classpath.
- Backends and separateOutputDirs are configured via an outputOptions
  closure or action.
- `AsciidoctorJEpub` plugin has been added which adds a single
  `asciidoctorEpub` task and configures it accordingly to EPUB behaviour.
  It also sets a default version of the `asciidoctorj-epub` dependency.
- Epub output formats can be set via the `ebookFormats` method.
- Additional Kindlegen plugin which is invoked by EPUB for when the format
  is KF8. The plugin will bootstrap kindlegen on all supported platforms.
- Work around gradle/gradle#3698 and Xerces API
  clash by running EPub conversions using `inProcess = JAVA_EXEC`. Also
  depend on `groovy-all` dependency rather than `localGroovy()` to see if
  that provides relief for the issue.
- All methods on the new task classes that take closures as parameters now
  also have equivalent Action parameters (asciidoctor#236).
- All new tasks are supportd by integration tests and compatibility tests. (asciidoctor#180)
- Various tests use a combination of JRuby & AsciidoctorJ versions to test
  compatibility at the integration test level.

Known issues:
- Intermittent failures in tests related to bad file descriptor. Could be
  similar to asciidoctor/asciidoctorj#442.
- EPUB3 + KF8 in one task (PendingFeature). Both formats in one task is
  currently failing. The exact failure message depends on which order
  (KF8+EPUB3 or EPUB3+KF8) the conversion takes place in.
- KF8 conversions fails under Windows.
  Related to asciidoctor/asciidoctorj#659 & jruby/jruby#4943.
- Does not work with JDK9 (but does with JDK10).
- Extensions only work for AsciidoctorJ 1.5.x

Backwards compatibility and migration:
- Legacy code moved to 'org.asciidoctor.gradle.compat' package,
  but get AsciidoctorTask in same package for compatibility purpose.
- Renamed AsciidoctorPlugin to AsciidoctorCompatibilityPlugin.
- Legacy plugin cannot be used with other Asciidoctor plugins within
  the same project.
- Existing 1.5.x deprecated methods has been removed from legacy
  AsciidoctorTask.

General:
- The version series is 2.0.0. It will be kept as alpha releases for
  a while.
- Project restructured into multiple plugins using 'base' plugin model
  for Asciidoctor plugins.
- Only support Gradle 4.0+.
- Only support JDK8+.
- For Gradle 4.5+ migration messages are controlled via `--warning-mode`.
- For Gradle 4.0-4.4 migration messages are controlled via `--info`.
- Additional text will be displayed on Gradle Plugin Portal for during
  alpha & beta releases.
- Compatibility testing has been added and initialy against Gradle
  versions 4.0.2, 4.3.1 & 4.6. (For JDK10 only test against 4.7).
- Some integration tests contain JRuby compatibility tests. Current test
  set is 1.7.27, 9.0.5.0/9.1.0.0, 9.1.17.0, 9.2.0.0.
- JDK compatibility testing are done from JDK8 -> JDK10 (Travis)
- Codenarc settings has been updated to find configuration from within
  subprojects.
- Updated license headers to include 2018.
- Integration tests utilises an offline Ivy repository (via Ivypot plugin)
  to reduce bandwith usage and test time.
- AsciidoctorJ, GroovyDSL etc. versions are defined in code and read by the
  build script. This provides one point of definition and ensure that code
  can have appropriate default versions.
- Test versions of JRuby and AsciidoctorJ is controlled via test fixtures.
- Renamed AsciidoctorPlugin to AsciidoctorCompatiblityPlugin
- Provide ability to either use AsciidoctorJ or AsciidoctorJS as the
  engine. (In this commit only AsciidoctorJ is implemented).
- Test result logged in real-time when running on Appveyor.

New generation AsciidoctorJ plugins and tasks:
- New (JVM) AsciidoctorJ extension can be added to both project & tasks.
  Extension in task can be used to override global settings from the
  project extension. It takes into account some of the ideas @manuelprinz
  had for asciidoctor#231 for is much more extensive.
- Extension has support for Asciidoctor verbose mode (asciidoctor#233).
  If `verboseMode` is set then a temporary file will be created and made
  part of Asciidoctor `requires`.
- AsciidoctorJ v1.6.0-alpha.6 is the default version, but it is possible
  to set a 1.5.x version if required.
- JRuby version can be controlled at both project and task level. If no
  version is specified at either level, the maximum of default the JRuby
  version that AsciidoctorJ depends on and a coded minimum safe version
  of JRuby, will be used.
- AsciidoctorJExtension maintains it's own detached configuration which
  can be fine turned via resolution strategies for edge cases.
- the `org.asciidoctor.jvm.base` plugin adds a dependency report
  specifically for the detached configuration.
- GroovyDSL extensions are now registered either on the project extension
  or the task extensions. The extensions are only loaded within a worker
  instance. The asciidoctor task is unloaded at the end of the worker and
  with it the extensions. (asciidoctor#166)
- AsciidoctorTask differentitates between top-level sources, secondary
  sources and resources in order to have a better idea of being
  out-of-date. (asciidoctor#185)
- It is possible to control whether resources should be copied or not. This
  allows a build to better deal with a backend such as PDF, which do not
  need resources to be copied.
- It is possible to perform the conversion from an intermediate working
  directory, which allows for a source directory to be kept pristine from
  intermediate artifacts generated from extensions such as ditaa.
- Using a worker approach for running Asciidoctor instances. (asciidoctor#220)
- Asciidoctor tasks can be configured to run AsciidoctorJ conversions in
  or out of process. Even when running in process AsciidoctorJ will be on
  an isolated classpath.
- Tasks support parallel mode which will run each backend (or in the case
  of Epub, each output format) in a separate worker. This behevaiour can
  be turned off in which case only one Asciidoctor instance is used to run
  all conversions in sequence.
- For cases where Gradle's idea of supplementing the classpath for workers
  do fail, there is a special `inProcess = JAVA_EXEC` that will run the
  conversion out of process, albeit less efficient than an out-of-process
  worker.
- Due to Gradle API classpath leakage, builds with Gradle 4.0-4.2 will
  always run in `JAVA_EXEC` mode to prevent issues.
- `AsciidoctorJPdf` plugin has been added which adds a single
  `asciidoctorPdf` task and configures it accordingly to PDF behaviour.
  It also sets a default version of the `asciidoctorj-pdf` dependency.
- If the PDF backend is used and the JRuby version starts with '9.x'
  then place SnakeYaml v1.13 on the classpath.
- Backends and separateOutputDirs are configured via an outputOptions
  closure or action.
- `AsciidoctorJEpub` plugin has been added which adds a single
  `asciidoctorEpub` task and configures it accordingly to EPUB behaviour.
  It also sets a default version of the `asciidoctorj-epub` dependency.
- Epub output formats can be set via the `ebookFormats` method.
- Additional Kindlegen plugin which is invoked by EPUB for when the format
  is KF8. The plugin will bootstrap kindlegen on all supported platforms.
- Work around gradle/gradle#3698 and Xerces API
  clash by running EPub conversions using `inProcess = JAVA_EXEC`. Also
  depend on `groovy-all` dependency rather than `localGroovy()` to see if
  that provides relief for the issue.
- All methods on the new task classes that take closures as parameters now
  also have equivalent Action parameters (asciidoctor#236).
- All new tasks are supportd by integration tests and compatibility tests. (asciidoctor#180)
- Various tests use a combination of JRuby & AsciidoctorJ versions to test
  compatibility at the integration test level.

Known issues:
- Intermittent failures in tests related to bad file descriptor. Could be
  similar to asciidoctor/asciidoctorj#442.
- EPUB3 + KF8 in one task (PendingFeature). Both formats in one task is
  currently failing. The exact failure message depends on which order
  (KF8+EPUB3 or EPUB3+KF8) the conversion takes place in.
- KF8 conversions fails under Windows.
  Related to asciidoctor/asciidoctorj#659 & jruby/jruby#4943.
- Does not work with JDK9 (but does with JDK10).

Backwards compatibility and migration:
- Legacy code moved to 'org.asciidoctor.gradle.compat' package,
  but get AsciidoctorTask in same package for compatibility purpose.
- Renamed AsciidoctorPlugin to AsciidoctorCompatibilityPlugin.
- Legacy plugin cannot be used with other Asciidoctor plugins within
  the same project.
- Existing 1.5.x deprecated methods has been removed from legacy
  AsciidoctorTask.

General:
- The version series is 2.0.0. It will be kept as alpha releases for
  a while.
- Project restructured into multiple plugins using 'base' plugin model
  for Asciidoctor plugins.
- Only support Gradle 4.0+.
- Only support JDK8+.
- For Gradle 4.5+ migration messages are controlled via `--warning-mode`.
- For Gradle 4.0-4.4 migration messages are controlled via `--info`.
- Additional text will be displayed on Gradle Plugin Portal for during
  alpha & beta releases.
- Compatibility testing has been added and initialy against Gradle
  versions 4.0.2, 4.3.1 & 4.6. (For JDK10 only test against 4.7).
- Some integration tests contain JRuby compatibility tests. Current test
  set is 1.7.27, 9.0.5.0/9.1.0.0, 9.1.17.0, 9.2.0.0.
- JDK compatibility testing are done from JDK8 -> JDK10 (Travis)
- Codenarc settings has been updated to find configuration from within
  subprojects.
- Updated license headers to include 2018.
- Integration tests utilises an offline Ivy repository (via Ivypot plugin)
  to reduce bandwith usage and test time.
- AsciidoctorJ, GroovyDSL etc. versions are defined in code and read by the
  build script. This provides one point of definition and ensure that code
  can have appropriate default versions.
- Test versions of JRuby and AsciidoctorJ is controlled via test fixtures.
- Renamed AsciidoctorPlugin to AsciidoctorCompatiblityPlugin
- Provide ability to either use AsciidoctorJ or AsciidoctorJS as the
  engine. (In this commit only AsciidoctorJ is implemented).
- Test result logged in real-time when running on Appveyor.

New generation AsciidoctorJ plugins and tasks:
- New (JVM) AsciidoctorJ extension can be added to both project & tasks.
  Extension in task can be used to override global settings from the
  project extension. It takes into account some of the ideas @manuelprinz
  had for asciidoctor#231 for is much more extensive.
- Extension has support for Asciidoctor verbose mode (asciidoctor#233).
  If `verboseMode` is set then a temporary file will be created and made
  part of Asciidoctor `requires`.
- AsciidoctorJ v1.6.0-alpha.6 is the default version, but it is possible
  to set a 1.5.x version if required.
- JRuby version can be controlled at both project and task level. If no
  version is specified at either level, the maximum of default the JRuby
  version that AsciidoctorJ depends on and a coded minimum safe version
  of JRuby, will be used.
- AsciidoctorJExtension maintains it's own detached configuration which
  can be fine turned via resolution strategies for edge cases.
- the `org.asciidoctor.jvm.base` plugin adds a dependency report
  specifically for the detached configuration.
- GroovyDSL extensions are now registered either on the project extension
  or the task extensions. The extensions are only loaded within a worker
  instance. The asciidoctor task is unloaded at the end of the worker and
  with it the extensions. (asciidoctor#166)
- AsciidoctorTask differentitates between top-level sources, secondary
  sources and resources in order to have a better idea of being
  out-of-date. (asciidoctor#185)
- It is possible to control whether resources should be copied or not. This
  allows a build to better deal with a backend such as PDF, which do not
  need resources to be copied.
- It is possible to perform the conversion from an intermediate working
  directory, which allows for a source directory to be kept pristine from
  intermediate artifacts generated from extensions such as ditaa.
- Using a worker approach for running Asciidoctor instances. (asciidoctor#220)
- Asciidoctor tasks can be configured to run AsciidoctorJ conversions in
  or out of process. Even when running in process AsciidoctorJ will be on
  an isolated classpath.
- Tasks support parallel mode which will run each backend (or in the case
  of Epub, each output format) in a separate worker. This behevaiour can
  be turned off in which case only one Asciidoctor instance is used to run
  all conversions in sequence.
- For cases where Gradle's idea of supplementing the classpath for workers
  do fail, there is a special `inProcess = JAVA_EXEC` that will run the
  conversion out of process, albeit less efficient than an out-of-process
  worker.
- Due to Gradle API classpath leakage, builds with Gradle 4.0-4.2 will
  always run in `JAVA_EXEC` mode to prevent issues.
- `AsciidoctorJPdf` plugin has been added which adds a single
  `asciidoctorPdf` task and configures it accordingly to PDF behaviour.
  It also sets a default version of the `asciidoctorj-pdf` dependency.
- If the PDF backend is used and the JRuby version starts with '9.x'
  then place SnakeYaml v1.13 on the classpath.
- Backends and separateOutputDirs are configured via an outputOptions
  closure or action.
- `AsciidoctorJEpub` plugin has been added which adds a single
  `asciidoctorEpub` task and configures it accordingly to EPUB behaviour.
  It also sets a default version of the `asciidoctorj-epub` dependency.
- Epub output formats can be set via the `ebookFormats` method.
- Additional Kindlegen plugin which is invoked by EPUB for when the format
  is KF8. The plugin will bootstrap kindlegen on all supported platforms.
- Work around gradle/gradle#3698 and Xerces API
  clash by running EPub conversions using `inProcess = JAVA_EXEC`. Also
  depend on `groovy-all` dependency rather than `localGroovy()` to see if
  that provides relief for the issue.
- All methods on the new task classes that take closures as parameters now
  also have equivalent Action parameters (asciidoctor#236).
- All new tasks are supportd by integration tests and compatibility tests. (asciidoctor#180)
- Various tests use a combination of JRuby & AsciidoctorJ versions to test
  compatibility at the integration test level.

Known issues:
- Intermittent failures in tests related to bad file descriptor. Could be
  similar to asciidoctor/asciidoctorj#442.
- EPUB3 + KF8 in one task (PendingFeature). Both formats in one task is
  currently failing. The exact failure message depends on which order
  (KF8+EPUB3 or EPUB3+KF8) the conversion takes place in.
- KF8 conversions fails under Windows.
  Related to asciidoctor/asciidoctorj#659 & jruby/jruby#4943.
- Does not work with JDK9 (but does with JDK10).

Backwards compatibility and migration:
- Legacy code moved to 'org.asciidoctor.gradle.compat' package,
  but get AsciidoctorTask in same package for compatibility purpose.
- Renamed AsciidoctorPlugin to AsciidoctorCompatibilityPlugin.
- Legacy plugin cannot be used with other Asciidoctor plugins within
  the same project.
- Existing 1.5.x deprecated methods has been removed from legacy
  AsciidoctorTask.

General:
- The version series is 2.0.0. It will be kept as alpha releases for
  a while.
- Project restructured into multiple plugins using 'base' plugin model
  for Asciidoctor plugins.
- Only support Gradle 4.0+.
- Only support JDK8+.
- For Gradle 4.5+ migration messages are controlled via `--warning-mode`.
- For Gradle 4.0-4.4 migration messages are controlled via `--info`.
- Additional text will be displayed on Gradle Plugin Portal for during
  alpha & beta releases.
- Compatibility testing has been added and initialy against Gradle
  versions 4.0.2, 4.3.1 & 4.6. (For JDK10 only test against 4.7).
- Some integration tests contain JRuby compatibility tests. Current test
  set is 1.7.27, 9.0.5.0/9.1.0.0, 9.1.17.0, 9.2.0.0.
- JDK compatibility testing are done from JDK8 -> JDK10 (Travis)
- Codenarc settings has been updated to find configuration from within
  subprojects.
- Updated license headers to include 2018.
- Integration tests utilises an offline Ivy repository (via Ivypot plugin)
  to reduce bandwith usage and test time.
- AsciidoctorJ, GroovyDSL etc. versions are defined in code and read by the
  build script. This provides one point of definition and ensure that code
  can have appropriate default versions.
- Test versions of JRuby and AsciidoctorJ is controlled via test fixtures.
- Renamed AsciidoctorPlugin to AsciidoctorCompatiblityPlugin
- Provide ability to either use AsciidoctorJ or AsciidoctorJS as the
  engine. (In this commit only AsciidoctorJ is implemented).
- Test result logged in real-time when running on Appveyor.

New generation AsciidoctorJ plugins and tasks:
- New (JVM) AsciidoctorJ extension can be added to both project & tasks.
  Extension in task can be used to override global settings from the
  project extension. It takes into account some of the ideas @manuelprinz
  had for asciidoctor#231 for is much more extensive.
- Extension has support for Asciidoctor verbose mode (asciidoctor#233).
  If `verboseMode` is set then a temporary file will be created and made
  part of Asciidoctor `requires`.
- AsciidoctorJ v1.6.0-alpha.6 is the default version, but it is possible
  to set a 1.5.x version if required.
- JRuby version can be controlled at both project and task level. If no
  version is specified at either level, the maximum of default the JRuby
  version that AsciidoctorJ depends on and a coded minimum safe version
  of JRuby, will be used.
- AsciidoctorJExtension maintains it's own detached configuration which
  can be fine turned via resolution strategies for edge cases.
- the `org.asciidoctor.jvm.base` plugin adds a dependency report
  specifically for the detached configuration.
- GroovyDSL extensions are now registered either on the project extension
  or the task extensions. The extensions are only loaded within a worker
  instance. The asciidoctor task is unloaded at the end of the worker and
  with it the extensions. (asciidoctor#166)
- AsciidoctorTask differentitates between top-level sources, secondary
  sources and resources in order to have a better idea of being
  out-of-date. (asciidoctor#185)
- It is possible to control whether resources should be copied or not. This
  allows a build to better deal with a backend such as PDF, which do not
  need resources to be copied.
- It is possible to perform the conversion from an intermediate working
  directory, which allows for a source directory to be kept pristine from
  intermediate artifacts generated from extensions such as ditaa.
- Using a worker approach for running Asciidoctor instances. (asciidoctor#220)
- Asciidoctor tasks can be configured to run AsciidoctorJ conversions in
  or out of process. Even when running in process AsciidoctorJ will be on
  an isolated classpath.
- Tasks support parallel mode which will run each backend (or in the case
  of Epub, each output format) in a separate worker. This behevaiour can
  be turned off in which case only one Asciidoctor instance is used to run
  all conversions in sequence.
- For cases where Gradle's idea of supplementing the classpath for workers
  do fail, there is a special `inProcess = JAVA_EXEC` that will run the
  conversion out of process, albeit less efficient than an out-of-process
  worker.
- Due to Gradle API classpath leakage, builds with Gradle 4.0-4.2 will
  always run in `JAVA_EXEC` mode to prevent issues.
- `AsciidoctorJPdf` plugin has been added which adds a single
  `asciidoctorPdf` task and configures it accordingly to PDF behaviour.
  It also sets a default version of the `asciidoctorj-pdf` dependency.
- If the PDF backend is used and the JRuby version starts with '9.x'
  then place SnakeYaml v1.13 on the classpath.
- Backends and separateOutputDirs are configured via an outputOptions
  closure or action.
- `AsciidoctorJEpub` plugin has been added which adds a single
  `asciidoctorEpub` task and configures it accordingly to EPUB behaviour.
  It also sets a default version of the `asciidoctorj-epub` dependency.
- Epub output formats can be set via the `ebookFormats` method.
- Additional Kindlegen plugin which is invoked by EPUB for when the format
  is KF8. The plugin will bootstrap kindlegen on all supported platforms.
- Work around gradle/gradle#3698 and Xerces API
  clash by running EPub conversions using `inProcess = JAVA_EXEC`. Also
  depend on `groovy-all` dependency rather than `localGroovy()` to see if
  that provides relief for the issue.
- All methods on the new task classes that take closures as parameters now
  also have equivalent Action parameters (asciidoctor#236).
- All new tasks are supportd by integration tests and compatibility tests. (asciidoctor#180)
- Various tests use a combination of JRuby & AsciidoctorJ versions to test
  compatibility at the integration test level.

Known issues:
- Intermittent failures in tests related to bad file descriptor. Could be
  similar to asciidoctor/asciidoctorj#442.
- EPUB3 + KF8 in one task (PendingFeature). Both formats in one task is
  currently failing. The exact failure message depends on which order
  (KF8+EPUB3 or EPUB3+KF8) the conversion takes place in.
- KF8 conversions fails under Windows.
  Related to asciidoctor/asciidoctorj#659 & jruby/jruby#4943.
- Does not work with JDK9 (but does with JDK10).

Backwards compatibility and migration:
- Legacy code moved to 'org.asciidoctor.gradle.compat' package,
  but get AsciidoctorTask in same package for compatibility purpose.
- Renamed AsciidoctorPlugin to AsciidoctorCompatibilityPlugin.
- Legacy plugin cannot be used with other Asciidoctor plugins within
  the same project.
- Existing 1.5.x deprecated methods has been removed from legacy
  AsciidoctorTask.

General:
- The version series is 2.0.0. It will be kept as alpha releases for
  a while.
- Project restructured into multiple plugins using 'base' plugin model
  for Asciidoctor plugins.
- Only support Gradle 4.0+.
- Only support JDK8+.
- For Gradle 4.5+ migration messages are controlled via `--warning-mode`.
- For Gradle 4.0-4.4 migration messages are controlled via `--info`.
- Additional text will be displayed on Gradle Plugin Portal for during
  alpha & beta releases.
- Compatibility testing has been added and initialy against Gradle
  versions 4.0.2, 4.3.1 & 4.6. (For JDK10 only test against 4.7).
- Some integration tests contain JRuby compatibility tests. Current test
  set is 1.7.27, 9.0.5.0/9.1.0.0, 9.1.17.0, 9.2.0.0.
- JDK compatibility testing are done from JDK8 -> JDK10 (Travis)
- Codenarc settings has been updated to find configuration from within
  subprojects.
- Updated license headers to include 2018.
- Integration tests utilises an offline Ivy repository (via Ivypot plugin)
  to reduce bandwith usage and test time.
- AsciidoctorJ, GroovyDSL etc. versions are defined in code and read by the
  build script. This provides one point of definition and ensure that code
  can have appropriate default versions.
- Test versions of JRuby and AsciidoctorJ is controlled via test fixtures.
- Renamed AsciidoctorPlugin to AsciidoctorCompatiblityPlugin
- Provide ability to either use AsciidoctorJ or AsciidoctorJS as the
  engine. (In this commit only AsciidoctorJ is implemented).
- Test result logged in real-time when running on Appveyor.

New generation AsciidoctorJ plugins and tasks:
- New (JVM) AsciidoctorJ extension can be added to both project & tasks.
  Extension in task can be used to override global settings from the
  project extension. It takes into account some of the ideas @manuelprinz
  had for asciidoctor#231 for is much more extensive.
- Extension has support for Asciidoctor verbose mode (asciidoctor#233).
  If `verboseMode` is set then a temporary file will be created and made
  part of Asciidoctor `requires`.
- AsciidoctorJ v1.6.0-alpha.6 is the default version, but it is possible
  to set a 1.5.x version if required.
- JRuby version can be controlled at both project and task level. If no
  version is specified at either level, the maximum of default the JRuby
  version that AsciidoctorJ depends on and a coded minimum safe version
  of JRuby, will be used.
- AsciidoctorJExtension maintains it's own detached configuration which
  can be fine turned via resolution strategies for edge cases.
- the `org.asciidoctor.jvm.base` plugin adds a dependency report
  specifically for the detached configuration.
- GroovyDSL extensions are now registered either on the project extension
  or the task extensions. The extensions are only loaded within a worker
  instance. The asciidoctor task is unloaded at the end of the worker and
  with it the extensions. (asciidoctor#166)
- AsciidoctorTask differentitates between top-level sources, secondary
  sources and resources in order to have a better idea of being
  out-of-date. (asciidoctor#185)
- It is possible to control whether resources should be copied or not. This
  allows a build to better deal with a backend such as PDF, which do not
  need resources to be copied.
- It is possible to perform the conversion from an intermediate working
  directory, which allows for a source directory to be kept pristine from
  intermediate artifacts generated from extensions such as ditaa.
- Using a worker approach for running Asciidoctor instances. (asciidoctor#220)
- Asciidoctor tasks can be configured to run AsciidoctorJ conversions in
  or out of process. Even when running in process AsciidoctorJ will be on
  an isolated classpath.
- Tasks support parallel mode which will run each backend (or in the case
  of Epub, each output format) in a separate worker. This behevaiour can
  be turned off in which case only one Asciidoctor instance is used to run
  all conversions in sequence.
- For cases where Gradle's idea of supplementing the classpath for workers
  do fail, there is a special `inProcess = JAVA_EXEC` that will run the
  conversion out of process, albeit less efficient than an out-of-process
  worker.
- Due to Gradle API classpath leakage, builds with Gradle 4.0-4.2 will
  always run in `JAVA_EXEC` mode to prevent issues.
- `AsciidoctorJPdf` plugin has been added which adds a single
  `asciidoctorPdf` task and configures it accordingly to PDF behaviour.
  It also sets a default version of the `asciidoctorj-pdf` dependency.
- If the PDF backend is used and the JRuby version starts with '9.x'
  then place SnakeYaml v1.13 on the classpath.
- Backends and separateOutputDirs are configured via an outputOptions
  closure or action.
- `AsciidoctorJEpub` plugin has been added which adds a single
  `asciidoctorEpub` task and configures it accordingly to EPUB behaviour.
  It also sets a default version of the `asciidoctorj-epub` dependency.
- Epub output formats can be set via the `ebookFormats` method.
- Additional Kindlegen plugin which is invoked by EPUB for when the format
  is KF8. The plugin will bootstrap kindlegen on all supported platforms.
- Work around gradle/gradle#3698 and Xerces API
  clash by running EPub conversions using `inProcess = JAVA_EXEC`. Also
  depend on `groovy-all` dependency rather than `localGroovy()` to see if
  that provides relief for the issue.
- Asciidoctorj-diagram supprot is in-built. Just specify the version on the
  extension and the artifact will be added to the classpatj. The necessary
  addition will be made to `requires` as well.
- All methods on the new task classes that take closures as parameters now
  also have equivalent Action parameters (asciidoctor#236).
- All new tasks are supportd by integration tests and compatibility tests. (asciidoctor#180)
- Various tests use a combination of JRuby & AsciidoctorJ versions to test
  compatibility at the integration test level.

Known issues:
- Intermittent failures in tests related to bad file descriptor. Could be
  similar to asciidoctor/asciidoctorj#442.
- EPUB3 + KF8 in one task (PendingFeature). Both formats in one task is
  currently failing. The exact failure message depends on which order
  (KF8+EPUB3 or EPUB3+KF8) the conversion takes place in.
- KF8 conversions fails under Windows.
  Related to asciidoctor/asciidoctorj#659 & jruby/jruby#4943.
- Does not work with JDK9 (but does with JDK10).

Backwards compatibility and migration:
- Legacy code moved to 'org.asciidoctor.gradle.compat' package,
  but get AsciidoctorTask in same package for compatibility purpose.
- Renamed AsciidoctorPlugin to AsciidoctorCompatibilityPlugin.
- Legacy plugin cannot be used with other Asciidoctor plugins within
  the same project.
- Existing 1.5.x deprecated methods has been removed from legacy
  AsciidoctorTask.
- asciidoctor#238 has been forard-ported to
  check that the same issue do not occur when using the compatibility
  task.

General:
- The version series is 2.0.0. It will be kept as alpha releases for
  a while.
- Project restructured into multiple plugins using 'base' plugin model
  for Asciidoctor plugins.
- Only support Gradle 4.0+.
- Only support JDK8+.
- For Gradle 4.5+ migration messages are controlled via `--warning-mode`.
- For Gradle 4.0-4.4 migration messages are controlled via `--info`.
- Additional text will be displayed on Gradle Plugin Portal for during
  alpha & beta releases.
- Compatibility testing has been added and initialy against Gradle
  versions 4.0.2, 4.3.1 & 4.6. (For JDK10 only test against 4.7).
- Some integration tests contain JRuby compatibility tests. Current test
  set is 1.7.27, 9.0.5.0/9.1.0.0, 9.1.17.0, 9.2.0.0.
- JDK compatibility testing are done from JDK8 -> JDK10 (Travis)
- Codenarc settings has been updated to find configuration from within
  subprojects.
- Updated license headers to include 2018.
- Integration tests utilises an offline Ivy repository (via Ivypot plugin)
  to reduce bandwith usage and test time.
- AsciidoctorJ, GroovyDSL etc. versions are defined in code and read by the
  build script. This provides one point of definition and ensure that code
  can have appropriate default versions.
- Test versions of JRuby and AsciidoctorJ is controlled via test fixtures.
- Renamed AsciidoctorPlugin to AsciidoctorCompatiblityPlugin
- Provide ability to either use AsciidoctorJ or AsciidoctorJS as the
  engine. (In this commit only AsciidoctorJ is implemented).
- Test result logged in real-time when running on Appveyor.

New generation AsciidoctorJ plugins and tasks:
- New (JVM) AsciidoctorJ extension can be added to both project & tasks.
  Extension in task can be used to override global settings from the
  project extension. It takes into account some of the ideas @manuelprinz
  had for asciidoctor#231 for is much more extensive.
- Extension has support for Asciidoctor verbose mode (asciidoctor#233).
  If `verboseMode` is set then a temporary file will be created and made
  part of Asciidoctor `requires`.
- AsciidoctorJ v1.6.0-alpha.6 is the default version, but it is possible
  to set a 1.5.x version if required.
- JRuby version can be controlled at both project and task level. If no
  version is specified at either level, the maximum of default the JRuby
  version that AsciidoctorJ depends on and a coded minimum safe version
  of JRuby, will be used.
- AsciidoctorJExtension maintains it's own detached configuration which
  can be fine turned via resolution strategies for edge cases.
- the `org.asciidoctor.jvm.base` plugin adds a dependency report
  specifically for the detached configuration.
- GroovyDSL extensions are now registered either on the project extension
  or the task extensions. The extensions are only loaded within a worker
  instance. The asciidoctor task is unloaded at the end of the worker and
  with it the extensions. (asciidoctor#166)
- AsciidoctorTask differentitates between top-level sources, secondary
  sources and resources in order to have a better idea of being
  out-of-date. (asciidoctor#185)
- It is possible to control whether resources should be copied or not. This
  allows a build to better deal with a backend such as PDF, which do not
  need resources to be copied.
- It is possible to perform the conversion from an intermediate working
  directory, which allows for a source directory to be kept pristine from
  intermediate artifacts generated from extensions such as ditaa.
- Using a worker approach for running Asciidoctor instances. (asciidoctor#220)
- Asciidoctor tasks can be configured to run AsciidoctorJ conversions in
  or out of process. Even when running in process AsciidoctorJ will be on
  an isolated classpath.
- Tasks support parallel mode which will run each backend (or in the case
  of Epub, each output format) in a separate worker. This behevaiour can
  be turned off in which case only one Asciidoctor instance is used to run
  all conversions in sequence.
- For cases where Gradle's idea of supplementing the classpath for workers
  do fail, there is a special `inProcess = JAVA_EXEC` that will run the
  conversion out of process, albeit less efficient than an out-of-process
  worker.
- Due to Gradle API classpath leakage, builds with Gradle 4.0-4.2 will
  always run in `JAVA_EXEC` mode to prevent issues.
- `AsciidoctorJPdf` plugin has been added which adds a single
  `asciidoctorPdf` task and configures it accordingly to PDF behaviour.
  It also sets a default version of the `asciidoctorj-pdf` dependency.
- If the PDF backend is used and the JRuby version starts with '9.x'
  then place SnakeYaml v1.13 on the classpath.
- Backends and separateOutputDirs are configured via an outputOptions
  closure or action.
- `AsciidoctorJEpub` plugin has been added which adds a single
  `asciidoctorEpub` task and configures it accordingly to EPUB behaviour.
  It also sets a default version of the `asciidoctorj-epub` dependency.
- Epub output formats can be set via the `ebookFormats` method.
- Additional Kindlegen plugin which is invoked by EPUB for when the format
  is KF8. The plugin will bootstrap kindlegen on all supported platforms.
- Work around gradle/gradle#3698 and Xerces API
  clash by running EPub conversions using `inProcess = JAVA_EXEC`. Also
  depend on `groovy-all` dependency rather than `localGroovy()` to see if
  that provides relief for the issue.
- Asciidoctorj-diagram supprot is in-built. Just specify the version on the
  extension and the artifact will be added to the classpatj. The necessary
  addition will be made to `requires` as well.
- All methods on the new task classes that take closures as parameters now
  also have equivalent Action parameters (asciidoctor#236).
- All new tasks are supportd by integration tests and compatibility tests. (asciidoctor#180)
- Various tests use a combination of JRuby & AsciidoctorJ versions to test
  compatibility at the integration test level.

Known issues:
- Intermittent failures in tests related to bad file descriptor. Could be
  similar to asciidoctor/asciidoctorj#442.
- EPUB3 + KF8 in one task (PendingFeature). Both formats in one task is
  currently failing. The exact failure message depends on which order
  (KF8+EPUB3 or EPUB3+KF8) the conversion takes place in.
- KF8 conversions fails under Windows.
  Related to asciidoctor/asciidoctorj#659 & jruby/jruby#4943.
- Does not work with JDK9 (but does with JDK10).

Backwards compatibility and migration:
- Legacy code moved to 'org.asciidoctor.gradle.compat' package,
  but get AsciidoctorTask in same package for compatibility purpose.
- Renamed AsciidoctorPlugin to AsciidoctorCompatibilityPlugin.
- Legacy plugin cannot be used with other Asciidoctor plugins within
  the same project.
- Existing 1.5.x deprecated methods has been removed from legacy
  AsciidoctorTask.
- asciidoctor#238 has been forard-ported to
  check that the same issue do not occur when using the compatibility
  task.

General:
- The version series is 2.0.0. It will be kept as alpha releases for
  a while.
- Project restructured into multiple plugins using 'base' plugin model
  for Asciidoctor plugins.
- Only support Gradle 4.0+.
- Only support JDK8+.
- For Gradle 4.5+ migration messages are controlled via `--warning-mode`.
- For Gradle 4.0-4.4 migration messages are controlled via `--info`.
- Additional text will be displayed on Gradle Plugin Portal for during
  alpha & beta releases.
- Compatibility testing has been added and initialy against Gradle
  versions 4.0.2, 4.3.1 & 4.6. (For JDK10 only test against 4.7).
- Some integration tests contain JRuby compatibility tests. Current test
  set is 1.7.27, 9.0.5.0/9.1.0.0, 9.1.17.0, 9.2.0.0.
- JDK compatibility testing are done from JDK8 -> JDK10 (Travis)
- Codenarc settings has been updated to find configuration from within
  subprojects.
- Updated license headers to include 2018.
- Integration tests utilises an offline Ivy repository (via Ivypot plugin)
  to reduce bandwith usage and test time.
- AsciidoctorJ, GroovyDSL etc. versions are defined in code and read by the
  build script. This provides one point of definition and ensure that code
  can have appropriate default versions.
- Test versions of JRuby and AsciidoctorJ is controlled via test fixtures.
- Renamed AsciidoctorPlugin to AsciidoctorCompatiblityPlugin
- Provide ability to either use AsciidoctorJ or AsciidoctorJS as the
  engine. (In this commit only AsciidoctorJ is implemented).
- Test result logged in real-time when running on Appveyor.

New generation AsciidoctorJ plugins and tasks:
- New (JVM) AsciidoctorJ extension can be added to both project & tasks.
  Extension in task can be used to override global settings from the
  project extension. It takes into account some of the ideas @manuelprinz
  had for asciidoctor#231 for is much more extensive.
- Extension has support for Asciidoctor verbose mode (asciidoctor#233).
  If `verboseMode` is set then a temporary file will be created and made
  part of Asciidoctor `requires`.
- AsciidoctorJ v1.6.0-alpha.6 is the default version, but it is possible
  to set a 1.5.x version if required.
- JRuby version can be controlled at both project and task level. If no
  version is specified at either level, the maximum of default the JRuby
  version that AsciidoctorJ depends on and a coded minimum safe version
  of JRuby, will be used.
- AsciidoctorJExtension maintains it's own detached configuration which
  can be fine turned via resolution strategies for edge cases.
- the `org.asciidoctor.jvm.base` plugin adds a dependency report
  specifically for the detached configuration.
- GroovyDSL extensions are now registered either on the project extension
  or the task extensions. The extensions are only loaded within a worker
  instance. The asciidoctor task is unloaded at the end of the worker and
  with it the extensions. (asciidoctor#166)
- AsciidoctorTask differentitates between top-level sources, secondary
  sources and resources in order to have a better idea of being
  out-of-date. (asciidoctor#185)
- It is possible to control whether resources should be copied or not. This
  allows a build to better deal with a backend such as PDF, which do not
  need resources to be copied.
- It is possible to perform the conversion from an intermediate working
  directory, which allows for a source directory to be kept pristine from
  intermediate artifacts generated from extensions such as ditaa.
- Using a worker approach for running Asciidoctor instances. (asciidoctor#220)
- Asciidoctor tasks can be configured to run AsciidoctorJ conversions in
  or out of process. Even when running in process AsciidoctorJ will be on
  an isolated classpath.
- Tasks support parallel mode which will run each backend (or in the case
  of Epub, each output format) in a separate worker. This behevaiour can
  be turned off in which case only one Asciidoctor instance is used to run
  all conversions in sequence.
- For cases where Gradle's idea of supplementing the classpath for workers
  do fail, there is a special `inProcess = JAVA_EXEC` that will run the
  conversion out of process, albeit less efficient than an out-of-process
  worker.
- Due to Gradle API classpath leakage, builds with Gradle 4.0-4.2 will
  always run in `JAVA_EXEC` mode to prevent issues.
- `AsciidoctorJPdf` plugin has been added which adds a single
  `asciidoctorPdf` task and configures it accordingly to PDF behaviour.
  It also sets a default version of the `asciidoctorj-pdf` dependency.
- If the PDF backend is used and the JRuby version starts with '9.x'
  then place SnakeYaml v1.13 on the classpath.
- Backends and separateOutputDirs are configured via an outputOptions
  closure or action.
- `AsciidoctorJEpub` plugin has been added which adds a single
  `asciidoctorEpub` task and configures it accordingly to EPUB behaviour.
  It also sets a default version of the `asciidoctorj-epub` dependency.
- Epub output formats can be set via the `ebookFormats` method.
- Additional Kindlegen plugin which is invoked by EPUB for when the format
  is KF8. The plugin will bootstrap kindlegen on all supported platforms.
- Work around gradle/gradle#3698 and Xerces API
  clash by running EPub conversions using `inProcess = JAVA_EXEC`. Also
  depend on `groovy-all` dependency rather than `localGroovy()` to see if
  that provides relief for the issue.
- Asciidoctorj-diagram supprot is in-built. Just specify the version on the
  extension and the artifact will be added to the classpatj. The necessary
  addition will be made to `requires` as well.
- All methods on the new task classes that take closures as parameters now
  also have equivalent Action parameters (asciidoctor#236).
- All new tasks are supportd by integration tests and compatibility tests. (asciidoctor#180)
- Various tests use a combination of JRuby & AsciidoctorJ versions to test
  compatibility at the integration test level.

Known issues:
- Intermittent failures in tests related to bad file descriptor. Could be
  similar to asciidoctor/asciidoctorj#442.
- EPUB3 + KF8 in one task (PendingFeature). Both formats in one task is
  currently failing. The exact failure message depends on which order
  (KF8+EPUB3 or EPUB3+KF8) the conversion takes place in.
- KF8 conversions fails under Windows.
  Related to asciidoctor/asciidoctorj#659 & jruby/jruby#4943.
- Does not work with JDK9 (but does with JDK10).

Backwards compatibility and migration:
- Legacy code moved to 'org.asciidoctor.gradle.compat' package,
  but get AsciidoctorTask in same package for compatibility purpose.
- Renamed AsciidoctorPlugin to AsciidoctorCompatibilityPlugin.
- Legacy plugin cannot be used with other Asciidoctor plugins within
  the same project.
- Existing 1.5.x deprecated methods has been removed from legacy
  AsciidoctorTask.
- asciidoctor#238 has been forard-ported to
  check that the same issue do not occur when using the compatibility
  task.

General:
- The version series is 2.0.0. It will be kept as alpha releases for
  a while.
- Project restructured into multiple plugins using 'base' plugin model
  for Asciidoctor plugins.
- Only support Gradle 4.0+.
- Only support JDK8+.
- For Gradle 4.5+ migration messages are controlled via `--warning-mode`.
- For Gradle 4.0-4.4 migration messages are controlled via `--info`.
- Additional text will be displayed on Gradle Plugin Portal for during
  alpha & beta releases.
- Compatibility testing has been added and initialy against Gradle
  versions 4.0.2, 4.3.1 & 4.6. (For JDK10 only test against 4.7).
- Some integration tests contain JRuby compatibility tests. Current test
  set is 1.7.27, 9.0.5.0/9.1.0.0, 9.1.17.0, 9.2.0.0.
- JDK compatibility testing are done from JDK8 -> JDK10 (Travis)
- Codenarc settings has been updated to find configuration from within
  subprojects.
- Updated license headers to include 2018.
- Integration tests utilises an offline Ivy repository (via Ivypot plugin)
  to reduce bandwith usage and test time.
- AsciidoctorJ, GroovyDSL etc. versions are defined in code and read by the
  build script. This provides one point of definition and ensure that code
  can have appropriate default versions.
- Test versions of JRuby and AsciidoctorJ is controlled via test fixtures.
- Renamed AsciidoctorPlugin to AsciidoctorCompatiblityPlugin
- Provide ability to either use AsciidoctorJ or AsciidoctorJS as the
  engine. (In this commit only AsciidoctorJ is implemented).
- Test result logged in real-time when running on Appveyor.

New generation AsciidoctorJ plugins and tasks:
- New (JVM) AsciidoctorJ extension can be added to both project & tasks.
  Extension in task can be used to override global settings from the
  project extension. It takes into account some of the ideas @manuelprinz
  had for asciidoctor#231 for is much more extensive.
- Extension has support for Asciidoctor verbose mode (asciidoctor#233).
  If `verboseMode` is set then a temporary file will be created and made
  part of Asciidoctor `requires`.
- AsciidoctorJ v1.6.0-alpha.6 is the default version, but it is possible
  to set a 1.5.x version if required.
- JRuby version can be controlled at both project and task level. If no
  version is specified at either level, the maximum of default the JRuby
  version that AsciidoctorJ depends on and a coded minimum safe version
  of JRuby, will be used.
- AsciidoctorJExtension maintains it's own detached configuration which
  can be fine turned via resolution strategies for edge cases.
- the `org.asciidoctor.jvm.base` plugin adds a dependency report
  specifically for the detached configuration.
- GroovyDSL extensions are now registered either on the project extension
  or the task extensions. The extensions are only loaded within a worker
  instance. The asciidoctor task is unloaded at the end of the worker and
  with it the extensions. (asciidoctor#166)
- AsciidoctorTask differentitates between top-level sources, secondary
  sources and resources in order to have a better idea of being
  out-of-date. (asciidoctor#185)
- It is possible to control whether resources should be copied or not. This
  allows a build to better deal with a backend such as PDF, which do not
  need resources to be copied.
- It is possible to perform the conversion from an intermediate working
  directory, which allows for a source directory to be kept pristine from
  intermediate artifacts generated from extensions such as ditaa.
- Using a worker approach for running Asciidoctor instances. (asciidoctor#220)
- Asciidoctor tasks can be configured to run AsciidoctorJ conversions in
  or out of process. Even when running in process AsciidoctorJ will be on
  an isolated classpath.
- Tasks support parallel mode which will run each backend (or in the case
  of Epub, each output format) in a separate worker. This behevaiour can
  be turned off in which case only one Asciidoctor instance is used to run
  all conversions in sequence.
- For cases where Gradle's idea of supplementing the classpath for workers
  do fail, there is a special `inProcess = JAVA_EXEC` that will run the
  conversion out of process, albeit less efficient than an out-of-process
  worker.
- Due to Gradle API classpath leakage, builds with Gradle 4.0-4.2 will
  always run in `JAVA_EXEC` mode to prevent issues.
- `AsciidoctorJPdf` plugin has been added which adds a single
  `asciidoctorPdf` task and configures it accordingly to PDF behaviour.
  It also sets a default version of the `asciidoctorj-pdf` dependency.
- If the PDF backend is used and the JRuby version starts with '9.x'
  then place SnakeYaml v1.13 on the classpath.
- Backends and separateOutputDirs are configured via an outputOptions
  closure or action.
- `AsciidoctorJEpub` plugin has been added which adds a single
  `asciidoctorEpub` task and configures it accordingly to EPUB behaviour.
  It also sets a default version of the `asciidoctorj-epub` dependency.
- Epub output formats can be set via the `ebookFormats` method.
- Additional Kindlegen plugin which is invoked by EPUB for when the format
  is KF8. The plugin will bootstrap kindlegen on all supported platforms.
- Work around gradle/gradle#3698 and Xerces API
  clash by running EPub conversions using `inProcess = JAVA_EXEC`. Also
  depend on `groovy-all` dependency rather than `localGroovy()` to see if
  that provides relief for the issue.
- Asciidoctorj-diagram supprot is in-built. Just specify the version on the
  extension and the artifact will be added to the classpatj. The necessary
  addition will be made to `requires` as well.
- All methods on the new task classes that take closures as parameters now
  also have equivalent Action parameters (asciidoctor#236).
- All new tasks are supportd by integration tests and compatibility tests. (asciidoctor#180)
- Various tests use a combination of JRuby & AsciidoctorJ versions to test
  compatibility at the integration test level.

Known issues:
- Intermittent failures in tests related to bad file descriptor. Could be
  similar to asciidoctor/asciidoctorj#442.
- EPUB3 + KF8 in one task (PendingFeature). Both formats in one task is
  currently failing. The exact failure message depends on which order
  (KF8+EPUB3 or EPUB3+KF8) the conversion takes place in.
- KF8 conversions fails under Windows.
  Related to asciidoctor/asciidoctorj#659 & jruby/jruby#4943.
- Does not work with JDK9 (but does with JDK10).

Backwards compatibility and migration:
- Legacy code moved to 'org.asciidoctor.gradle.compat' package,
  but get AsciidoctorTask in same package for compatibility purpose.
- Renamed AsciidoctorPlugin to AsciidoctorCompatibilityPlugin.
- Legacy plugin cannot be used with other Asciidoctor plugins within
  the same project.
- Existing 1.5.x deprecated methods has been removed from legacy
  AsciidoctorTask.
- asciidoctor#238 has been forard-ported to
  check that the same issue do not occur when using the compatibility
  task.

General:
- The version series is 2.0.0. It will be kept as alpha releases for
  a while.
- Project restructured into multiple plugins using 'base' plugin model
  for Asciidoctor plugins.
- Only support Gradle 4.0+.
- Only support JDK8+.
- For Gradle 4.5+ migration messages are controlled via `--warning-mode`.
- For Gradle 4.0-4.4 migration messages are controlled via `--info`.
- Additional text will be displayed on Gradle Plugin Portal for during
  alpha & beta releases.
- Compatibility testing has been added and initialy against Gradle
  versions 4.0.2, 4.3.1 & 4.6. (For JDK10 only test against 4.7).
- Some integration tests contain JRuby compatibility tests. Current test
  set is 1.7.27, 9.0.5.0/9.1.0.0, 9.1.17.0, 9.2.0.0.
- JDK compatibility testing are done from JDK8 -> JDK10 (Travis)
- Codenarc settings has been updated to find configuration from within
  subprojects.
- Updated license headers to include 2018.
- Integration tests utilises an offline Ivy repository (via Ivypot plugin)
  to reduce bandwith usage and test time.
- AsciidoctorJ, GroovyDSL etc. versions are defined in code and read by the
  build script. This provides one point of definition and ensure that code
  can have appropriate default versions.
- Test versions of JRuby and AsciidoctorJ is controlled via test fixtures.
- Renamed AsciidoctorPlugin to AsciidoctorCompatiblityPlugin
- Provide ability to either use AsciidoctorJ or AsciidoctorJS as the
  engine. (In this commit only AsciidoctorJ is implemented).
- Test result logged in real-time when running on Appveyor.

New generation AsciidoctorJ plugins and tasks:
- New (JVM) AsciidoctorJ extension can be added to both project & tasks.
  Extension in task can be used to override global settings from the
  project extension. It takes into account some of the ideas @manuelprinz
  had for asciidoctor#231 for is much more extensive.
- Extension has support for Asciidoctor verbose mode (asciidoctor#233).
  If `verboseMode` is set then a temporary file will be created and made
  part of Asciidoctor `requires`.
- AsciidoctorJ v1.6.0-alpha.6 is the default version, but it is possible
  to set a 1.5.x version if required.
- JRuby version can be controlled at both project and task level. If no
  version is specified at either level, the maximum of default the JRuby
  version that AsciidoctorJ depends on and a coded minimum safe version
  of JRuby, will be used.
- AsciidoctorJExtension maintains it's own detached configuration which
  can be fine turned via resolution strategies for edge cases.
- the `org.asciidoctor.jvm.base` plugin adds a dependency report
  specifically for the detached configuration.
- GroovyDSL extensions are now registered either on the project extension
  or the task extensions. The extensions are only loaded within a worker
  instance. The asciidoctor task is unloaded at the end of the worker and
  with it the extensions. (asciidoctor#166)
- AsciidoctorTask differentitates between top-level sources, secondary
  sources and resources in order to have a better idea of being
  out-of-date. (asciidoctor#185)
- It is possible to control whether resources should be copied or not. This
  allows a build to better deal with a backend such as PDF, which do not
  need resources to be copied.
- It is possible to perform the conversion from an intermediate working
  directory, which allows for a source directory to be kept pristine from
  intermediate artifacts generated from extensions such as ditaa.
- Using a worker approach for running Asciidoctor instances. (asciidoctor#220)
- Asciidoctor tasks can be configured to run AsciidoctorJ conversions in
  or out of process. Even when running in process AsciidoctorJ will be on
  an isolated classpath.
- Tasks support parallel mode which will run each backend (or in the case
  of Epub, each output format) in a separate worker. This behevaiour can
  be turned off in which case only one Asciidoctor instance is used to run
  all conversions in sequence.
- For cases where Gradle's idea of supplementing the classpath for workers
  do fail, there is a special `inProcess = JAVA_EXEC` that will run the
  conversion out of process, albeit less efficient than an out-of-process
  worker.
- Due to Gradle API classpath leakage, builds with Gradle 4.0-4.2 will
  always run in `JAVA_EXEC` mode to prevent issues.
- `AsciidoctorJPdf` plugin has been added which adds a single
  `asciidoctorPdf` task and configures it accordingly to PDF behaviour.
  It also sets a default version of the `asciidoctorj-pdf` dependency.
- If the PDF backend is used and the JRuby version starts with '9.x'
  then place SnakeYaml v1.13 on the classpath.
- Backends and separateOutputDirs are configured via an outputOptions
  closure or action.
- `AsciidoctorJEpub` plugin has been added which adds a single
  `asciidoctorEpub` task and configures it accordingly to EPUB behaviour.
  It also sets a default version of the `asciidoctorj-epub` dependency.
- Epub output formats can be set via the `ebookFormats` method.
- Additional Kindlegen plugin which is invoked by EPUB for when the format
  is KF8. The plugin will bootstrap kindlegen on all supported platforms.
- Work around gradle/gradle#3698 and Xerces API
  clash by running EPub conversions using `inProcess = JAVA_EXEC`. Also
  depend on `groovy-all` dependency rather than `localGroovy()` to see if
  that provides relief for the issue.
- Asciidoctorj-diagram supprot is in-built. Just specify the version on the
  extension and the artifact will be added to the classpatj. The necessary
  addition will be made to `requires` as well.
- All methods on the new task classes that take closures as parameters now
  also have equivalent Action parameters (asciidoctor#236).
- All new tasks are supportd by integration tests and compatibility tests. (asciidoctor#180)
- Various tests use a combination of JRuby & AsciidoctorJ versions to test
  compatibility at the integration test level.

Known issues:
- Intermittent failures in tests related to bad file descriptor. Could be
  similar to asciidoctor/asciidoctorj#442.
- EPUB3 + KF8 in one task (PendingFeature). Both formats in one task is
  currently failing. The exact failure message depends on which order
  (KF8+EPUB3 or EPUB3+KF8) the conversion takes place in.
- KF8 conversions fails under Windows.
  Related to asciidoctor/asciidoctorj#659 & jruby/jruby#4943.
- Does not work with JDK9 (but does with JDK10).

Backwards compatibility and migration:
- Legacy code moved to 'org.asciidoctor.gradle.compat' package,
  but get AsciidoctorTask in same package for compatibility purpose.
- Renamed AsciidoctorPlugin to AsciidoctorCompatibilityPlugin.
- Legacy plugin cannot be used with other Asciidoctor plugins within
  the same project.
- Existing 1.5.x deprecated methods has been removed from legacy
  AsciidoctorTask.
- asciidoctor#238 has been forard-ported to
  check that the same issue do not occur when using the compatibility
  task.

General:
- The version series is 2.0.0. It will be kept as alpha releases for
  a while.
- Project restructured into multiple plugins using 'base' plugin model
  for Asciidoctor plugins.
- Only support Gradle 4.0+.
- Only support JDK8+.
- For Gradle 4.5+ migration messages are controlled via `--warning-mode`.
- For Gradle 4.0-4.4 migration messages are controlled via `--info`.
- Additional text will be displayed on Gradle Plugin Portal for during
  alpha & beta releases.
- Compatibility testing has been added and initialy against Gradle
  versions 4.0.2, 4.3.1 & 4.6. (For JDK10 only test against 4.7).
- Some integration tests contain JRuby compatibility tests. Current test
  set is 1.7.27, 9.0.5.0/9.1.0.0, 9.1.17.0, 9.2.0.0.
- JDK compatibility testing are done from JDK8 -> JDK10 (Travis)
- Codenarc settings has been updated to find configuration from within
  subprojects.
- Updated license headers to include 2018.
- Integration tests utilises an offline Ivy repository (via Ivypot plugin)
  to reduce bandwith usage and test time.
- AsciidoctorJ, GroovyDSL etc. versions are defined in code and read by the
  build script. This provides one point of definition and ensure that code
  can have appropriate default versions.
- Test versions of JRuby and AsciidoctorJ is controlled via test fixtures.
- Renamed AsciidoctorPlugin to AsciidoctorCompatiblityPlugin
- Provide ability to either use AsciidoctorJ or AsciidoctorJS as the
  engine. (In this commit only AsciidoctorJ is implemented).
- Test result logged in real-time when running on Appveyor.

New generation AsciidoctorJ plugins and tasks:
- New (JVM) AsciidoctorJ extension can be added to both project & tasks.
  Extension in task can be used to override global settings from the
  project extension. It takes into account some of the ideas @manuelprinz
  had for asciidoctor#231 for is much more extensive.
- Extension has support for Asciidoctor verbose mode (asciidoctor#233).
  If `verboseMode` is set then a temporary file will be created and made
  part of Asciidoctor `requires`.
- AsciidoctorJ v1.6.0-alpha.6 is the default version, but it is possible
  to set a 1.5.x version if required.
- JRuby version can be controlled at both project and task level. If no
  version is specified at either level, the maximum of default the JRuby
  version that AsciidoctorJ depends on and a coded minimum safe version
  of JRuby, will be used.
- AsciidoctorJExtension maintains it's own detached configuration which
  can be fine turned via resolution strategies for edge cases.
- the `org.asciidoctor.jvm.base` plugin adds a dependency report
  specifically for the detached configuration.
- GroovyDSL extensions are now registered either on the project extension
  or the task extensions. The extensions are only loaded within a worker
  instance. The asciidoctor task is unloaded at the end of the worker and
  with it the extensions. (asciidoctor#166)
- AsciidoctorTask differentitates between top-level sources, secondary
  sources and resources in order to have a better idea of being
  out-of-date. (asciidoctor#185)
- It is possible to control whether resources should be copied or not. This
  allows a build to better deal with a backend such as PDF, which do not
  need resources to be copied.
- It is possible to perform the conversion from an intermediate working
  directory, which allows for a source directory to be kept pristine from
  intermediate artifacts generated from extensions such as ditaa.
- Using a worker approach for running Asciidoctor instances. (asciidoctor#220)
- Asciidoctor tasks can be configured to run AsciidoctorJ conversions in
  or out of process. Even when running in process AsciidoctorJ will be on
  an isolated classpath.
- Tasks support parallel mode which will run each backend (or in the case
  of Epub, each output format) in a separate worker. This behevaiour can
  be turned off in which case only one Asciidoctor instance is used to run
  all conversions in sequence.
- For cases where Gradle's idea of supplementing the classpath for workers
  do fail, there is a special `inProcess = JAVA_EXEC` that will run the
  conversion out of process, albeit less efficient than an out-of-process
  worker.
- Due to Gradle API classpath leakage, builds with Gradle 4.0-4.2 will
  always run in `JAVA_EXEC` mode to prevent issues.
- `AsciidoctorJPdf` plugin has been added which adds a single
  `asciidoctorPdf` task and configures it accordingly to PDF behaviour.
  It also sets a default version of the `asciidoctorj-pdf` dependency.
- If the PDF backend is used and the JRuby version starts with '9.x'
  then place SnakeYaml v1.13 on the classpath.
- Backends and separateOutputDirs are configured via an outputOptions
  closure or action.
- `AsciidoctorJEpub` plugin has been added which adds a single
  `asciidoctorEpub` task and configures it accordingly to EPUB behaviour.
  It also sets a default version of the `asciidoctorj-epub` dependency.
- Epub output formats can be set via the `ebookFormats` method.
- Additional Kindlegen plugin which is invoked by EPUB for when the format
  is KF8. The plugin will bootstrap kindlegen on all supported platforms.
- Work around gradle/gradle#3698 and Xerces API
  clash by running EPub conversions using `inProcess = JAVA_EXEC`. Also
  depend on `groovy-all` dependency rather than `localGroovy()` to see if
  that provides relief for the issue.
- Asciidoctorj-diagram supprot is in-built. Just specify the version on the
  extension and the artifact will be added to the classpatj. The necessary
  addition will be made to `requires` as well.
- All methods on the new task classes that take closures as parameters now
  also have equivalent Action parameters (asciidoctor#236).
- All new tasks are supportd by integration tests and compatibility tests. (asciidoctor#180)
- Various tests use a combination of JRuby & AsciidoctorJ versions to test
  compatibility at the integration test level.

Known issues:
- Intermittent failures in tests related to bad file descriptor. Could be
  similar to asciidoctor/asciidoctorj#442.
- EPUB3 + KF8 in one task (PendingFeature). Both formats in one task is
  currently failing. The exact failure message depends on which order
  (KF8+EPUB3 or EPUB3+KF8) the conversion takes place in.
- KF8 conversions fails under Windows.
  Related to asciidoctor/asciidoctorj#659 & jruby/jruby#4943.
- Does not work with JDK9 (but does with JDK10).

Backwards compatibility and migration:
- Legacy code moved to 'org.asciidoctor.gradle.compat' package,
  but get AsciidoctorTask in same package for compatibility purpose.
- Renamed AsciidoctorPlugin to AsciidoctorCompatibilityPlugin.
- Legacy plugin cannot be used with other Asciidoctor plugins within
  the same project.
- Existing 1.5.x deprecated methods has been removed from legacy
  AsciidoctorTask.
- asciidoctor#238 has been forard-ported to
  check that the same issue do not occur when using the compatibility
  task.

General:
- The version series is 2.0.0. It will be kept as alpha releases for
  a while.
- Project restructured into multiple plugins using 'base' plugin model
  for Asciidoctor plugins.
- Only support Gradle 4.0+.
- Only support JDK8+.
- For Gradle 4.5+ migration messages are controlled via `--warning-mode`.
- For Gradle 4.0-4.4 migration messages are controlled via `--info`.
- Additional text will be displayed on Gradle Plugin Portal for during
  alpha & beta releases.
- Compatibility testing has been added and initialy against Gradle
  versions 4.0.2, 4.3.1 & 4.6. (For JDK10 only test against 4.7).
- Some integration tests contain JRuby compatibility tests. Current test
  set is 1.7.27, 9.0.5.0/9.1.0.0, 9.1.17.0, 9.2.0.0.
- JDK compatibility testing are done from JDK8 -> JDK10 (Travis)
- Codenarc settings has been updated to find configuration from within
  subprojects.
- Updated license headers to include 2018.
- Integration tests utilises an offline Ivy repository (via Ivypot plugin)
  to reduce bandwith usage and test time.
- AsciidoctorJ, GroovyDSL etc. versions are defined in code and read by the
  build script. This provides one point of definition and ensure that code
  can have appropriate default versions.
- Test versions of JRuby and AsciidoctorJ is controlled via test fixtures.
- Renamed AsciidoctorPlugin to AsciidoctorCompatiblityPlugin
- Provide ability to either use AsciidoctorJ or AsciidoctorJS as the
  engine. (In this commit only AsciidoctorJ is implemented).
- Test result logged in real-time when running on Appveyor.

New generation AsciidoctorJ plugins and tasks:
- New (JVM) AsciidoctorJ extension can be added to both project & tasks.
  Extension in task can be used to override global settings from the
  project extension. It takes into account some of the ideas @manuelprinz
  had for asciidoctor#231 for is much more extensive.
- Extension has support for Asciidoctor verbose mode (asciidoctor#233).
  If `verboseMode` is set then a temporary file will be created and made
  part of Asciidoctor `requires`.
- AsciidoctorJ v1.6.0-alpha.6 is the default version, but it is possible
  to set a 1.5.x version if required.
- JRuby version can be controlled at both project and task level. If no
  version is specified at either level, the maximum of default the JRuby
  version that AsciidoctorJ depends on and a coded minimum safe version
  of JRuby, will be used.
- AsciidoctorJExtension maintains it's own detached configuration which
  can be fine turned via resolution strategies for edge cases.
- the `org.asciidoctor.jvm.base` plugin adds a dependency report
  specifically for the detached configuration.
- GroovyDSL extensions are now registered either on the project extension
  or the task extensions. The extensions are only loaded within a worker
  instance. The asciidoctor task is unloaded at the end of the worker and
  with it the extensions. (asciidoctor#166)
- AsciidoctorTask differentitates between top-level sources, secondary
  sources and resources in order to have a better idea of being
  out-of-date. (asciidoctor#185)
- It is possible to control whether resources should be copied or not. This
  allows a build to better deal with a backend such as PDF, which do not
  need resources to be copied.
- It is possible to perform the conversion from an intermediate working
  directory, which allows for a source directory to be kept pristine from
  intermediate artifacts generated from extensions such as ditaa.
- Using a worker approach for running Asciidoctor instances. (asciidoctor#220)
- Asciidoctor tasks can be configured to run AsciidoctorJ conversions in
  or out of process. Even when running in process AsciidoctorJ will be on
  an isolated classpath.
- Tasks support parallel mode which will run each backend (or in the case
  of Epub, each output format) in a separate worker. This behevaiour can
  be turned off in which case only one Asciidoctor instance is used to run
  all conversions in sequence.
- For cases where Gradle's idea of supplementing the classpath for workers
  do fail, there is a special `inProcess = JAVA_EXEC` that will run the
  conversion out of process, albeit less efficient than an out-of-process
  worker.
- Due to Gradle API classpath leakage, builds with Gradle 4.0-4.2 will
  always run in `JAVA_EXEC` mode to prevent issues.
- `AsciidoctorJPdf` plugin has been added which adds a single
  `asciidoctorPdf` task and configures it accordingly to PDF behaviour.
  It also sets a default version of the `asciidoctorj-pdf` dependency.
- If the PDF backend is used and the JRuby version starts with '9.x'
  then place SnakeYaml v1.13 on the classpath.
- Backends and separateOutputDirs are configured via an outputOptions
  closure or action.
- `AsciidoctorJEpub` plugin has been added which adds a single
  `asciidoctorEpub` task and configures it accordingly to EPUB behaviour.
  It also sets a default version of the `asciidoctorj-epub` dependency.
- Epub output formats can be set via the `ebookFormats` method.
- Additional Kindlegen plugin which is invoked by EPUB for when the format
  is KF8. The plugin will bootstrap kindlegen on all supported platforms.
- Work around gradle/gradle#3698 and Xerces API
  clash by running EPub conversions using `inProcess = JAVA_EXEC`. Also
  depend on `groovy-all` dependency rather than `localGroovy()` to see if
  that provides relief for the issue.
- Asciidoctorj-diagram supprot is in-built. Just specify the version on the
  extension and the artifact will be added to the classpatj. The necessary
  addition will be made to `requires` as well.
- All methods on the new task classes that take closures as parameters now
  also have equivalent Action parameters (asciidoctor#236).
- All new tasks are supportd by integration tests and compatibility tests. (asciidoctor#180)
- Various tests use a combination of JRuby & AsciidoctorJ versions to test
  compatibility at the integration test level.

Known issues:
- Intermittent failures in tests related to bad file descriptor. Could be
  similar to asciidoctor/asciidoctorj#442.
- EPUB3 + KF8 in one task (PendingFeature). Both formats in one task is
  currently failing. The exact failure message depends on which order
  (KF8+EPUB3 or EPUB3+KF8) the conversion takes place in.
- KF8 conversions fails under Windows.
  Related to asciidoctor/asciidoctorj#659 & jruby/jruby#4943.
- Does not work with JDK9 (but does with JDK10).

Backwards compatibility and migration:
- Legacy code moved to 'org.asciidoctor.gradle.compat' package,
  but get AsciidoctorTask in same package for compatibility purpose.
- Renamed AsciidoctorPlugin to AsciidoctorCompatibilityPlugin.
- Legacy plugin cannot be used with other Asciidoctor plugins within
  the same project.
- Existing 1.5.x deprecated methods has been removed from legacy
  AsciidoctorTask.
- asciidoctor#238 has been forard-ported to
  check that the same issue do not occur when using the compatibility
  task.

General:
- The version series is 2.0.0. It will be kept as alpha releases for
  a while.
- Project restructured into multiple plugins using 'base' plugin model
  for Asciidoctor plugins.
- Only support Gradle 4.0+.
- Only support JDK8+.
- For Gradle 4.5+ migration messages are controlled via `--warning-mode`.
- For Gradle 4.0-4.4 migration messages are controlled via `--info`.
- Additional text will be displayed on Gradle Plugin Portal for during
  alpha & beta releases.
- Compatibility testing has been added and initialy against Gradle
  versions 4.0.2, 4.3.1 & 4.6. (For JDK10 only test against 4.7).
- Some integration tests contain JRuby compatibility tests. Current test
  set is 1.7.27, 9.0.5.0/9.1.0.0, 9.1.17.0, 9.2.0.0.
- JDK compatibility testing are done from JDK8 -> JDK10 (Travis)
- Codenarc settings has been updated to find configuration from within
  subprojects.
- Updated license headers to include 2018.
- Integration tests utilises an offline Ivy repository (via Ivypot plugin)
  to reduce bandwith usage and test time.
- AsciidoctorJ, GroovyDSL etc. versions are defined in code and read by the
  build script. This provides one point of definition and ensure that code
  can have appropriate default versions.
- Test versions of JRuby and AsciidoctorJ is controlled via test fixtures.
- Renamed AsciidoctorPlugin to AsciidoctorCompatiblityPlugin
- Provide ability to either use AsciidoctorJ or AsciidoctorJS as the
  engine. (In this commit only AsciidoctorJ is implemented).
- Test result logged in real-time when running on Appveyor.

New generation AsciidoctorJ plugins and tasks:
- New (JVM) AsciidoctorJ extension can be added to both project & tasks.
  Extension in task can be used to override global settings from the
  project extension. It takes into account some of the ideas @manuelprinz
  had for asciidoctor#231 for is much more extensive.
- Extension has support for Asciidoctor verbose mode (asciidoctor#233).
  If `verboseMode` is set then a temporary file will be created and made
  part of Asciidoctor `requires`.
- AsciidoctorJ v1.6.0-alpha.6 is the default version, but it is possible
  to set a 1.5.x version if required.
- JRuby version can be controlled at both project and task level. If no
  version is specified at either level, the maximum of default the JRuby
  version that AsciidoctorJ depends on and a coded minimum safe version
  of JRuby, will be used.
- AsciidoctorJExtension maintains it's own detached configuration which
  can be fine turned via resolution strategies for edge cases.
- the `org.asciidoctor.jvm.base` plugin adds a dependency report
  specifically for the detached configuration.
- GroovyDSL extensions are now registered either on the project extension
  or the task extensions. The extensions are only loaded within a worker
  instance. The asciidoctor task is unloaded at the end of the worker and
  with it the extensions. (asciidoctor#166)
- AsciidoctorTask differentitates between top-level sources, secondary
  sources and resources in order to have a better idea of being
  out-of-date. (asciidoctor#185)
- It is possible to control whether resources should be copied or not. This
  allows a build to better deal with a backend such as PDF, which do not
  need resources to be copied.
- It is possible to perform the conversion from an intermediate working
  directory, which allows for a source directory to be kept pristine from
  intermediate artifacts generated from extensions such as ditaa.
- Using a worker approach for running Asciidoctor instances. (asciidoctor#220)
- Asciidoctor tasks can be configured to run AsciidoctorJ conversions in
  or out of process. Even when running in process AsciidoctorJ will be on
  an isolated classpath.
- Tasks support parallel mode which will run each backend (or in the case
  of Epub, each output format) in a separate worker. This behevaiour can
  be turned off in which case only one Asciidoctor instance is used to run
  all conversions in sequence.
- For cases where Gradle's idea of supplementing the classpath for workers
  do fail, there is a special `inProcess = JAVA_EXEC` that will run the
  conversion out of process, albeit less efficient than an out-of-process
  worker.
- Due to Gradle API classpath leakage, builds with Gradle 4.0-4.2 will
  always run in `JAVA_EXEC` mode to prevent issues.
- `AsciidoctorJPdf` plugin has been added which adds a single
  `asciidoctorPdf` task and configures it accordingly to PDF behaviour.
  It also sets a default version of the `asciidoctorj-pdf` dependency.
- If the PDF backend is used and the JRuby version starts with '9.x'
  then place SnakeYaml v1.13 on the classpath.
- Backends and separateOutputDirs are configured via an outputOptions
  closure or action.
- `AsciidoctorJEpub` plugin has been added which adds a single
  `asciidoctorEpub` task and configures it accordingly to EPUB behaviour.
  It also sets a default version of the `asciidoctorj-epub` dependency.
- Epub output formats can be set via the `ebookFormats` method.
- Additional Kindlegen plugin which is invoked by EPUB for when the format
  is KF8. The plugin will bootstrap kindlegen on all supported platforms.
- Work around gradle/gradle#3698 and Xerces API
  clash by running EPub conversions using `inProcess = JAVA_EXEC`. Also
  depend on `groovy-all` dependency rather than `localGroovy()` to see if
  that provides relief for the issue.
- Asciidoctorj-diagram supprot is in-built. Just specify the version on the
  extension and the artifact will be added to the classpatj. The necessary
  addition will be made to `requires` as well.
- All methods on the new task classes that take closures as parameters now
  also have equivalent Action parameters (asciidoctor#236).
- All new tasks are supportd by integration tests and compatibility tests. (asciidoctor#180)
- Various tests use a combination of JRuby & AsciidoctorJ versions to test
  compatibility at the integration test level.

Known issues:
- Intermittent failures in tests related to bad file descriptor. Could be
  similar to asciidoctor/asciidoctorj#442.
- EPUB3 + KF8 in one task (PendingFeature). Both formats in one task is
  currently failing. The exact failure message depends on which order
  (KF8+EPUB3 or EPUB3+KF8) the conversion takes place in.
- KF8 conversions fails under Windows.
  Related to asciidoctor/asciidoctorj#659 & jruby/jruby#4943.
- Does not work with JDK9 (but does with JDK10).

Backwards compatibility and migration:
- Legacy code moved to 'org.asciidoctor.gradle.compat' package,
  but get AsciidoctorTask in same package for compatibility purpose.
- Renamed AsciidoctorPlugin to AsciidoctorCompatibilityPlugin.
- Legacy plugin cannot be used with other Asciidoctor plugins within
  the same project.
- Existing 1.5.x deprecated methods has been removed from legacy
  AsciidoctorTask.
- asciidoctor#238 has been forard-ported to
  check that the same issue do not occur when using the compatibility
  task.

General:
- The version series is 2.0.0. It will be kept as alpha releases for
  a while.
- Project restructured into multiple plugins using 'base' plugin model
  for Asciidoctor plugins.
- Only support Gradle 4.0+.
- Only support JDK8+.
- For Gradle 4.5+ migration messages are controlled via `--warning-mode`.
- For Gradle 4.0-4.4 migration messages are controlled via `--info`.
- Additional text will be displayed on Gradle Plugin Portal for during
  alpha & beta releases.
- Compatibility testing has been added and initialy against Gradle
  versions 4.0.2, 4.3.1 & 4.6. (For JDK10 only test against 4.7).
- Some integration tests contain JRuby compatibility tests. Current test
  set is 1.7.27, 9.0.5.0/9.1.0.0, 9.1.17.0, 9.2.0.0.
- JDK compatibility testing are done from JDK8 -> JDK10 (Travis)
- Codenarc settings has been updated to find configuration from within
  subprojects.
- Updated license headers to include 2018.
- Integration tests utilises an offline Ivy repository (via Ivypot plugin)
  to reduce bandwith usage and test time.
- AsciidoctorJ, GroovyDSL etc. versions are defined in code and read by the
  build script. This provides one point of definition and ensure that code
  can have appropriate default versions.
- Test versions of JRuby and AsciidoctorJ is controlled via test fixtures.
- Renamed AsciidoctorPlugin to AsciidoctorCompatiblityPlugin
- Provide ability to either use AsciidoctorJ or AsciidoctorJS as the
  engine. (In this commit only AsciidoctorJ is implemented).
- Test result logged in real-time when running on Appveyor.

New generation AsciidoctorJ plugins and tasks:
- New (JVM) AsciidoctorJ extension can be added to both project & tasks.
  Extension in task can be used to override global settings from the
  project extension. It takes into account some of the ideas @manuelprinz
  had for asciidoctor#231 for is much more extensive.
- Extension has support for Asciidoctor verbose mode (asciidoctor#233).
  If `verboseMode` is set then a temporary file will be created and made
  part of Asciidoctor `requires`.
- AsciidoctorJ v1.6.0-alpha.6 is the default version, but it is possible
  to set a 1.5.x version if required.
- JRuby version can be controlled at both project and task level. If no
  version is specified at either level, the maximum of default the JRuby
  version that AsciidoctorJ depends on and a coded minimum safe version
  of JRuby, will be used.
- AsciidoctorJExtension maintains it's own detached configuration which
  can be fine turned via resolution strategies for edge cases.
- the `org.asciidoctor.jvm.base` plugin adds a dependency report
  specifically for the detached configuration.
- GroovyDSL extensions are now registered either on the project extension
  or the task extensions. The extensions are only loaded within a worker
  instance. The asciidoctor task is unloaded at the end of the worker and
  with it the extensions. (asciidoctor#166)
- AsciidoctorTask differentitates between top-level sources, secondary
  sources and resources in order to have a better idea of being
  out-of-date. (asciidoctor#185)
- It is possible to control whether resources should be copied or not. This
  allows a build to better deal with a backend such as PDF, which do not
  need resources to be copied.
- It is possible to perform the conversion from an intermediate working
  directory, which allows for a source directory to be kept pristine from
  intermediate artifacts generated from extensions such as ditaa.
- Using a worker approach for running Asciidoctor instances. (asciidoctor#220)
- Asciidoctor tasks can be configured to run AsciidoctorJ conversions in
  or out of process. Even when running in process AsciidoctorJ will be on
  an isolated classpath.
- Tasks support parallel mode which will run each backend (or in the case
  of Epub, each output format) in a separate worker. This behevaiour can
  be turned off in which case only one Asciidoctor instance is used to run
  all conversions in sequence.
- For cases where Gradle's idea of supplementing the classpath for workers
  do fail, there is a special `inProcess = JAVA_EXEC` that will run the
  conversion out of process, albeit less efficient than an out-of-process
  worker.
- Due to Gradle API classpath leakage, builds with Gradle 4.0-4.2 will
  always run in `JAVA_EXEC` mode to prevent issues.
- `AsciidoctorJPdf` plugin has been added which adds a single
  `asciidoctorPdf` task and configures it accordingly to PDF behaviour.
  It also sets a default version of the `asciidoctorj-pdf` dependency.
- If the PDF backend is used and the JRuby version starts with '9.x'
  then place SnakeYaml v1.13 on the classpath.
- Backends and separateOutputDirs are configured via an outputOptions
  closure or action.
- `AsciidoctorJEpub` plugin has been added which adds a single
  `asciidoctorEpub` task and configures it accordingly to EPUB behaviour.
  It also sets a default version of the `asciidoctorj-epub` dependency.
- Epub output formats can be set via the `ebookFormats` method.
- Additional Kindlegen plugin which is invoked by EPUB for when the format
  is KF8. The plugin will bootstrap kindlegen on all supported platforms.
- Work around gradle/gradle#3698 and Xerces API
  clash by running EPub conversions using `inProcess = JAVA_EXEC`. Also
  depend on `groovy-all` dependency rather than `localGroovy()` to see if
  that provides relief for the issue.
- Asciidoctorj-diagram supprot is in-built. Just specify the version on the
  extension and the artifact will be added to the classpatj. The necessary
  addition will be made to `requires` as well.
- All methods on the new task classes that take closures as parameters now
  also have equivalent Action parameters (asciidoctor#236).
- All new tasks are supportd by integration tests and compatibility tests. (asciidoctor#180)
- Various tests use a combination of JRuby & AsciidoctorJ versions to test
  compatibility at the integration test level.

Known issues:
- Intermittent failures in tests related to bad file descriptor. Could be
  similar to asciidoctor/asciidoctorj#442.
- EPUB3 + KF8 in one task (PendingFeature). Both formats in one task is
  currently failing. The exact failure message depends on which order
  (KF8+EPUB3 or EPUB3+KF8) the conversion takes place in.
- KF8 conversions fails under Windows.
  Related to asciidoctor/asciidoctorj#659 & jruby/jruby#4943.
- Does not work with JDK9 (but does with JDK10).

Backwards compatibility and migration:
- Legacy code moved to 'org.asciidoctor.gradle.compat' package,
  but get AsciidoctorTask in same package for compatibility purpose.
- Renamed AsciidoctorPlugin to AsciidoctorCompatibilityPlugin.
- Legacy plugin cannot be used with other Asciidoctor plugins within
  the same project.
- Existing 1.5.x deprecated methods has been removed from legacy
  AsciidoctorTask.
- asciidoctor#238 has been forard-ported to
  check that the same issue do not occur when using the compatibility
  task.