New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open3.open2e returns `Errno::ENOENT` in jRuby but runs fine on Ruby #4943

Open
abelsromero opened this Issue Jan 5, 2018 · 8 comments

Comments

Projects
None yet
3 participants
@abelsromero

abelsromero commented Jan 5, 2018

Environment

JRuby v 9.1.15.0
Run from IDE, no additional configurations.
Windows 7
Java 1.8.0_152

Expected Behavior

  • A script that runs a external command (kindlegen) using Open3.open2e should work on normal Ruby and jRuby.

Actual Behavior

  • The script works fine on Ruby 2.3.3, but fails when run through jRuby 9.1.15.0 showing (Errno::ENOENT). I assume the error is related to not being able to find some find. is that so?
  • Here is is a example project I created to reproduce the issue: https://github.com/abelsromero/jruby-open3-issue.
  1. Clone the project and create a KINDLEGEN environment var pointing to the kindlegen file in the files directory.
  2. Open cmd with Ruby available in PATH and go to the "files" directory.
  3. Run "ruby Open3Ruby.rb" --> Script should complete, generating a file called "spine.mobi" in the same directory. If you see the script code, several "puts" show how the actual files involved exist and are available.
  4. Open the project in IntelliJ. Run the class "RubyRunner". --> Execution will fail with message
C:\home\asalgadr\temp\jruby-open3-issue\.\files\kindlegen.exe
true
C:/home/asalgadr/temp/jruby-open3-issue/files/spine-kf8.epub
true
Exception in thread "main" org.jruby.exceptions.RaiseException: (Errno::ENOENT) C:\\home\\\asalgadr\\temp\\jruby-open3-issue\\.\\files\\kindlegen.exe -dont_append_source -c0 -o spine.mobi C:/home/asalgadr/temp/jruby-open3-issue/files/spine-kf8.epub
	at org.jruby.RubyProcess.spawn(org/jruby/RubyProcess.java:1569)
	at org.jruby.RubyKernel.spawn(org/jruby/RubyKernel.java:1511)
	at RUBY.popen_run(uri:classloader:/META-INF/jruby.home/lib/ruby/stdlib/jruby/open3_windows.rb:204)
	at RUBY.popen2e(uri:classloader:/META-INF/jruby.home/lib/ruby/stdlib/jruby/open3_windows.rb:199)
	at RUBY.<main>(<script>:26)

The first four lines are the puts that check that files involved are available.

@abelsromero

This comment has been minimized.

Show comment
Hide comment
@abelsromero

abelsromero Jan 6, 2018

I updated the test project to support MacOS.
In MacOS the issue does not appear and the script runs fine on both shell (Ruby 2.4.x) and jRuby.

abelsromero commented Jan 6, 2018

I updated the test project to support MacOS.
In MacOS the issue does not appear and the script runs fine on both shell (Ruby 2.4.x) and jRuby.

@headius

This comment has been minimized.

Show comment
Hide comment
@headius

headius Jan 10, 2018

Member

This is more fallout from Windows not getting the same subprocess love that unix platforms have gotten.

Member

headius commented Jan 10, 2018

This is more fallout from Windows not getting the same subprocess love that unix platforms have gotten.

@abelsromero

This comment has been minimized.

Show comment
Hide comment
@abelsromero

abelsromero Jan 11, 2018

This is more fallout from Windows

Windows...not surprised (╯°□°)╯︵ ┻━┻.
But the thing is, isn't there absolutely nothing that can be done?
Even if the implementation is not 100% compliant with the original Ruby implementation, but at least allows executing an external process and get the output.

abelsromero commented Jan 11, 2018

This is more fallout from Windows

Windows...not surprised (╯°□°)╯︵ ┻━┻.
But the thing is, isn't there absolutely nothing that can be done?
Even if the implementation is not 100% compliant with the original Ruby implementation, but at least allows executing an external process and get the output.

@headius

This comment has been minimized.

Show comment
Hide comment
@headius

headius Jan 11, 2018

Member

The issue is that the default implementation of Open3 wants to use lower-level IO and process APIs that don't work properly on Windows right now. So we have had to special-case Open3 methods on some platforms.

I'll look and see if we're just not special-casing this right.

Member

headius commented Jan 11, 2018

The issue is that the default implementation of Open3 wants to use lower-level IO and process APIs that don't work properly on Windows right now. So we have had to special-case Open3 methods on some platforms.

I'll look and see if we're just not special-casing this right.

headius added a commit that referenced this issue Jan 11, 2018

@headius

This comment has been minimized.

Show comment
Hide comment
@headius

headius Jan 11, 2018

Member

Ok, so we only special-case popen3, probably because that was the most likely one for people to use. However, we should be able to special-case the others, since they're mostly subsets of popen3.

I've started a PR to improve our Windows patches to open3.

Member

headius commented Jan 11, 2018

Ok, so we only special-case popen3, probably because that was the most likely one for people to use. However, we should be able to special-case the others, since they're mostly subsets of popen3.

I've started a PR to improve our Windows patches to open3.

@abelsromero

This comment has been minimized.

Show comment
Hide comment
@abelsromero

abelsromero Jan 12, 2018

I've started a PR to improve our Windows patches to open3.

Many thanks! Let me know when is ready to test.

abelsromero commented Jan 12, 2018

I've started a PR to improve our Windows patches to open3.

Many thanks! Let me know when is ready to test.

@headius

This comment has been minimized.

Show comment
Hide comment
@headius

headius Jan 29, 2018

Member

Link with #5018.

Member

headius commented Jan 29, 2018

Link with #5018.

@headius

This comment has been minimized.

Show comment
Hide comment
@headius

headius Feb 13, 2018

Member

The childprocess gem does indeed contain a pretty solid FFI implementation of process logic for Windows. I think that's the path forward, maybe for 9.2.

Member

headius commented Feb 13, 2018

The childprocess gem does indeed contain a pretty solid FFI implementation of process logic for Windows. I think that's the path forward, maybe for 9.2.

@headius headius added this to the JRuby 9.2.0.0 milestone Feb 13, 2018

@enebo enebo modified the milestones: JRuby 9.2.0.0, JRuby 9.2.1.0 May 24, 2018

ysb33r added a commit to ysb33r/asciidoctor-gradle-plugin that referenced this issue Jun 19, 2018

New generation Asciidoctor Gradle plugins
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.

ysb33r added a commit to ysb33r/asciidoctor-gradle-plugin that referenced this issue Jun 19, 2018

New generation Asciidoctor Gradle plugins
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.

ysb33r added a commit to ysb33r/asciidoctor-gradle-plugin that referenced this issue Jun 19, 2018

New generation Asciidoctor Gradle plugins
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.

ysb33r added a commit to ysb33r/asciidoctor-gradle-plugin that referenced this issue Jun 20, 2018

New generation Asciidoctor Gradle plugins
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.

ysb33r added a commit to ysb33r/asciidoctor-gradle-plugin that referenced this issue Jun 20, 2018

New generation Asciidoctor Gradle plugins
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.

ysb33r added a commit to ysb33r/asciidoctor-gradle-plugin that referenced this issue Jun 20, 2018

New generation Asciidoctor Gradle plugins
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.

ysb33r added a commit to ysb33r/asciidoctor-gradle-plugin that referenced this issue Jun 21, 2018

New generation Asciidoctor Gradle plugins
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.

ysb33r added a commit to ysb33r/asciidoctor-gradle-plugin that referenced this issue Jun 21, 2018

New generation Asciidoctor Gradle plugins
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.

ysb33r added a commit to ysb33r/asciidoctor-gradle-plugin that referenced this issue Jun 21, 2018

New generation Asciidoctor Gradle plugins
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.

ysb33r added a commit to ysb33r/asciidoctor-gradle-plugin that referenced this issue Jun 22, 2018

New generation Asciidoctor Gradle plugins
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.

ysb33r added a commit to ysb33r/asciidoctor-gradle-plugin that referenced this issue Jun 22, 2018

New generation Asciidoctor Gradle plugins
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.

ysb33r added a commit to ysb33r/asciidoctor-gradle-plugin that referenced this issue Jun 22, 2018

New generation Asciidoctor Gradle plugins
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.

ysb33r added a commit to ysb33r/asciidoctor-gradle-plugin that referenced this issue Jun 23, 2018

New generation Asciidoctor Gradle plugins
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.

ysb33r added a commit to ysb33r/asciidoctor-gradle-plugin that referenced this issue Jun 23, 2018

New generation Asciidoctor Gradle plugins
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.

ysb33r added a commit to ysb33r/asciidoctor-gradle-plugin that referenced this issue Jun 23, 2018

New generation Asciidoctor Gradle plugins
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.

ysb33r added a commit to ysb33r/asciidoctor-gradle-plugin that referenced this issue Jun 23, 2018

New generation Asciidoctor Gradle plugins
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.

ysb33r added a commit to ysb33r/asciidoctor-gradle-plugin that referenced this issue Jun 23, 2018

New generation Asciidoctor Gradle plugins
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.

ysb33r added a commit to ysb33r/asciidoctor-gradle-plugin that referenced this issue Jun 23, 2018

New generation Asciidoctor Gradle plugins
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.

ysb33r added a commit to ysb33r/asciidoctor-gradle-plugin that referenced this issue Jun 24, 2018

New generation Asciidoctor Gradle plugins
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.

ysb33r added a commit to ysb33r/asciidoctor-gradle-plugin that referenced this issue Jun 24, 2018

New generation Asciidoctor Gradle plugins
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.

ysb33r added a commit to ysb33r/asciidoctor-gradle-plugin that referenced this issue Jun 24, 2018

New generation Asciidoctor Gradle plugins
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.

ysb33r added a commit to ysb33r/asciidoctor-gradle-plugin that referenced this issue Jun 25, 2018

New generation Asciidoctor Gradle plugins
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.

ysb33r added a commit to ysb33r/asciidoctor-gradle-plugin that referenced this issue Jun 25, 2018

New generation Asciidoctor Gradle plugins
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.

ysb33r added a commit to ysb33r/asciidoctor-gradle-plugin that referenced this issue Jun 25, 2018

New generation Asciidoctor Gradle plugins
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.

ysb33r added a commit to ysb33r/asciidoctor-gradle-plugin that referenced this issue Jun 26, 2018

New generation Asciidoctor Gradle plugins
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.

ysb33r added a commit to ysb33r/asciidoctor-gradle-plugin that referenced this issue Jun 27, 2018

New generation Asciidoctor Gradle plugins
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.

ysb33r added a commit to ysb33r/asciidoctor-gradle-plugin that referenced this issue Jun 27, 2018

New generation Asciidoctor Gradle plugins
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.

ysb33r added a commit to ysb33r/asciidoctor-gradle-plugin that referenced this issue Jun 27, 2018

New generation Asciidoctor Gradle plugins
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.

ysb33r added a commit to ysb33r/asciidoctor-gradle-plugin that referenced this issue Jun 27, 2018

New generation Asciidoctor Gradle plugins
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.

ysb33r added a commit to ysb33r/asciidoctor-gradle-plugin that referenced this issue Jun 27, 2018

New generation Asciidoctor Gradle plugins
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.

ysb33r added a commit to ysb33r/asciidoctor-gradle-plugin that referenced this issue Jun 27, 2018

New generation Asciidoctor Gradle plugins
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment