Skip to content
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

Worker classpath should only contain necessary classes #3698

Closed
oehme opened this issue Dec 4, 2017 · 15 comments

Comments

@oehme
Copy link
Member

commented Dec 4, 2017

Given this trivial example, one can see that the whole classloader that loaded the work item implementation is added to the worker classpath. This includes all kinds of Gradle internals like Guava and Groovy as well as any other plugins that were loaded by the same project.

Instead, the worker server should only be started with the minimal set of classes to needed for that work item.

@oehme

This comment has been minimized.

Copy link
Member Author

commented Dec 4, 2017

@ghale I think our defaults are a bit too permissive here. Maybe we should only add the jar that the work item came from and ask the user to provide everything else using classpath()? Or we could do bytecode analysis and find all the types/jars that the work item needs.

@ghale

This comment has been minimized.

Copy link
Member

commented Dec 4, 2017

Yeah, this is something that should be made better. I was thinking we would extract org.gradle.tooling.internal.adapter.TypeInspector for this. I think that would be better than requiring input from the user and should handle the most common cases.

@tylerbenson

This comment has been minimized.

Copy link

commented Dec 5, 2017

This has been driving me nuts. I've been trying to figure out where dependencies are coming from when running jmh via the gradle plugin. For some reason two different versions of groovy are being pulled in and I couldn't figure out where they were coming from with the end result being exceptions like this:

Caused by: groovy.lang.GroovyRuntimeException: Conflicting module versions. Module [groovy-all is loaded in version 2.4.7 and you are trying to load version 2.4.12

After spending all day trying to figure out how the classpath became so big, I think this sounds very likely to be the problem.

Are there any work-arounds to reduce the classpath before the fork happens?
Thanks!

@obecker

This comment has been minimized.

Copy link

commented Apr 2, 2018

@tylerbenson just for the records since nobody has answered your question and I struggled with the same problem: adding configurations.all { exclude module: 'groovy-all' } to the buildscript closure will prevent this exception.

I faced this problem after migrating a custom plugin to the worker API. I decided to add an explicit dependency to org.codehaus.groovy:groovy-all:2.4.12 to the compile configuration of the plugin (though the plugin worker task actually doesn't need groovy) to enable gradle doing the correct conflict resolution.

I'm aware that this is only a workaround for the underlying problem, so I hope this issue gets fixed soon.

michalharakal added a commit to dukecon/dukecon_android that referenced this issue Apr 5, 2018
@ysb33r

This comment has been minimized.

Copy link
Contributor

commented Jun 12, 2018

I ran into this problem as well. I thought at first I was in classloader hell, having messed up things, now I'm glad others have seen it too. It has been pretty harmless in first implementations, but I have now run into an issue where plugins/xercesImpl-2.11.0.jar is interfering.

I think that would be better than requiring input from the user and should handle the most common cases.

I would prefer that there is some kind of override whether the user can decide whether Gradle's decision is good enought or whether the user wants full control over specifying the classpath.

ysb33r added a commit to ysb33r/asciidoctor-gradle-plugin that referenced this issue Jun 13, 2018
New generation Asciidoctor Gradle plugins
General:
- Use 'base' plugin model for Asciidoctor plugins.
- Only support Gradle 4.0+.
- For Gradle 4.5+ migration messages are controlled via `--warning-mode`.
- For Gradle 4.0-4.4 migration messages are controlled via `--info`.
- Supports JDK8+.
- Additional text will be displayed on Gradle Plugin Portal for during
  alpha & beta releases.
- Compatibility testing has been added and initialy against 4.0 and 4.6.
- Codenarc settings has been updated to find configuration from within
  subprojects.
- Updated license headers.
- Integration tests utilises an offline Ivy repository (via Ivypot plugin)
  to reduce bandwith usage and test time.

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`.
- 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 (ir in the case or 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.
- `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.
- 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)

EPub3 (PendingFeature):
- `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. Both formats
  can be generated within one task.
- Work around gradle/gradle#3698 and Xerces API
  clash by running EPub conversions using `inProcess = JAVA_EXEC`.

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 16, 2018
New generation Asciidoctor Gradle plugins
General:
- Use 'base' plugin model for Asciidoctor plugins.
- Only support Gradle 4.0+.
- For Gradle 4.5+ migration messages are controlled via `--warning-mode`.
- For Gradle 4.0-4.4 migration messages are controlled via `--info`.
- Supports JDK8+.
- Additional text will be displayed on Gradle Plugin Portal for during
  alpha & beta releases.
- Compatibility testing has been added and initialy against 4.0 and 4.6.
- Codenarc settings has been updated to find configuration from within
  subprojects.
- Updated license headers.
- Integration tests utilises an offline Ivy repository (via Ivypot plugin)
  to reduce bandwith usage and test time.

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 (ir in the case or 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.
- `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.
- 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)

EPub3 (PendingFeature):
- `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. Both formats
  can be generated within one task.
- 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`.

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 16, 2018
New generation Asciidoctor Gradle plugins
General:
- Use 'base' plugin model for Asciidoctor plugins.
- Only support Gradle 4.0+.
- For Gradle 4.5+ migration messages are controlled via `--warning-mode`.
- For Gradle 4.0-4.4 migration messages are controlled via `--info`.
- Supports JDK8+.
- Additional text will be displayed on Gradle Plugin Portal for during
  alpha & beta releases.
- Compatibility testing has been added and initialy against 4.0 and 4.6.
- Codenarc settings has been updated to find configuration from within
  subprojects.
- Updated license headers.
- Integration tests utilises an offline Ivy repository (via Ivypot plugin)
  to reduce bandwith usage and test time.

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 (ir in the case or 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.
- `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.
- 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)

EPub3 (PendingFeature):
- `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. Both formats
  can be generated within one task.
- 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`.

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 16, 2018
New generation Asciidoctor Gradle plugins
General:
- Use 'base' plugin model for Asciidoctor plugins.
- Only support Gradle 4.0+.
- For Gradle 4.5+ migration messages are controlled via `--warning-mode`.
- For Gradle 4.0-4.4 migration messages are controlled via `--info`.
- Supports JDK8+.
- Additional text will be displayed on Gradle Plugin Portal for during
  alpha & beta releases.
- Compatibility testing has been added and initialy against 4.0 and 4.6.
- Codenarc settings has been updated to find configuration from within
  subprojects.
- Updated license headers.
- 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 (ir in the case or 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.
- `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.
- 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)

EPUB3 (PendingFeature):
- `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. Both formats
  can be generated within one task.
- 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`.

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 16, 2018
New generation Asciidoctor Gradle plugins
General:
- Use 'base' plugin model for Asciidoctor plugins.
- Only support Gradle 4.0+.
- For Gradle 4.5+ migration messages are controlled via `--warning-mode`.
- For Gradle 4.0-4.4 migration messages are controlled via `--info`.
- Supports JDK8+.
- Additional text will be displayed on Gradle Plugin Portal for during
  alpha & beta releases.
- Compatibility testing has been added and initialy against 4.0 and 4.6.
- Codenarc settings has been updated to find configuration from within
  subprojects.
- Updated license headers.
- 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 (ir in the case or 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.
- `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)

EPUB3 + KF8 in one task (PendingFeature)
- Both formats in one task is currently failing

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 16, 2018
New generation Asciidoctor Gradle plugins
General:
- Use 'base' plugin model for Asciidoctor plugins.
- Only support Gradle 4.0+.
- For Gradle 4.5+ migration messages are controlled via `--warning-mode`.
- For Gradle 4.0-4.4 migration messages are controlled via `--info`.
- Supports JDK8+.
- Additional text will be displayed on Gradle Plugin Portal for during
  alpha & beta releases.
- Compatibility testing has been added and initialy against 4.0 and 4.6.
- Codenarc settings has been updated to find configuration from within
  subprojects.
- Updated license headers.
- 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 or 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)

EPUB3 + KF8 in one task (PendingFeature)
- Both formats in one task is currently failing

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 16, 2018
New generation Asciidoctor Gradle plugins
General:
- Use 'base' plugin model for Asciidoctor plugins.
- Only support Gradle 4.0+.
- For Gradle 4.5+ migration messages are controlled via `--warning-mode`.
- For Gradle 4.0-4.4 migration messages are controlled via `--info`.
- Supports JDK8+.
- Additional text will be displayed on Gradle Plugin Portal for during
  alpha & beta releases.
- Compatibility testing has been added and initialy against 4.0 and 4.6.
- Codenarc settings has been updated to find configuration from within
  subprojects.
- Updated license headers.
- 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 or 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)

EPUB3 + KF8 in one task (PendingFeature)
- Both formats in one task is currently failing

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 16, 2018
New generation Asciidoctor Gradle plugins
General:
- Use 'base' plugin model for Asciidoctor plugins.
- Only support Gradle 4.0+.
- For Gradle 4.5+ migration messages are controlled via `--warning-mode`.
- For Gradle 4.0-4.4 migration messages are controlled via `--info`.
- Supports JDK8+.
- Additional text will be displayed on Gradle Plugin Portal for during
  alpha & beta releases.
- Compatibility testing has been added and initialy against 4.0 and 4.6.
- Codenarc settings has been updated to find configuration from within
  subprojects.
- Updated license headers.
- 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 or 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)

EPUB3 + KF8 in one task (PendingFeature)
- Both formats in one task is currently failing

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 17, 2018
New generation Asciidoctor Gradle plugins
General:
- Use 'base' plugin model for Asciidoctor plugins.
- Only support Gradle 4.0+.
- For Gradle 4.5+ migration messages are controlled via `--warning-mode`.
- For Gradle 4.0-4.4 migration messages are controlled via `--info`.
- Supports JDK8+.
- Additional text will be displayed on Gradle Plugin Portal for during
  alpha & beta releases.
- Compatibility testing has been added and initialy against 4.0 and 4.6.
- Codenarc settings has been updated to find configuration from within
  subprojects.
- Updated license headers.
- 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)

EPUB3 + KF8 in one task (PendingFeature)
- Both formats in one task is currently failing

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 17, 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, 4.3 & 4.6.
- 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)

EPUB3 + KF8 in one task (PendingFeature)
- Both formats in one task is currently failing

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 17, 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, 4.3 & 4.6.
- 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)

EPUB3 + KF8 in one task (PendingFeature)
- Both formats in one task is currently failing

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 17, 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, 4.3 & 4.6.
- 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 failsures 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.

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 17, 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, 4.3 & 4.6.
- 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 failsures 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.

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 17, 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, 4.3 & 4.6.
- 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 failsures 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.

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 17, 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, 4.3 & 4.6.
- 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 failsures 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.

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 17, 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, 4.3 & 4.6.
- 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 failsures 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.

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 17, 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, 4.3 & 4.6.
- 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 failsures 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.

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 17, 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, 4.3 & 4.6.
- 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 failsures 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.

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 18, 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, 4.3 & 4.6.
- 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 failsures 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.

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 18, 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, 4.3 & 4.6.
- 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 failsures 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.

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 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.
@bootstraponline

This comment has been minimized.

Copy link

commented Jul 13, 2018

The 161 commits to Asciidoctor referencing this issue make me wonder if we should close it and open a new issue with a clean history.

@ysb33r

This comment has been minimized.

Copy link
Contributor

commented Nov 4, 2018

The 161 commits to Asciidoctor referencing this issue make me wonder if we should close it and open a new issue with a clean history.

Good idea

@ysb33r

This comment has been minimized.

Copy link
Contributor

commented Nov 4, 2018

I also ran into another related issue. When testing tasks using TestKit and the version of Groovy differs between the calling process and the task under test, the worker code injects groovy-all from both the calling process. This results in stacktraces containing

Caused by: groovy.lang.GroovyRuntimeException: Conflicting module versions. Module [groovy-all is loaded in version 2.4.12 and you are trying to load version 2.4.15
	at org.codehaus.groovy.runtime.metaclass.MetaClassRegistryImpl$DefaultModuleListener.onModule(MetaClassRegistryImpl.java:513)
	at org.codehaus.groovy.runtime.m12n.ExtensionModuleScanner.scanExtensionModuleFromProperties(ExtensionModuleScanner.java:80)
	at org.codehaus.groovy.runtime.m12n.ExtensionModuleScanner.scanExtensionModuleFromMetaInf(ExtensionModuleScanner.java:74)
	at org.codehaus.groovy.runtime.m12n.ExtensionModuleScanner.scanClasspathModules(ExtensionModuleScanner.java:56)
	at org.codehaus.groovy.runtime.metaclass.MetaClassRegistryImpl.<init>(MetaClassRegistryImpl.java:113)
	at org.codehaus.groovy.runtime.metaclass.MetaClassRegistryImpl.<init>(MetaClassRegistryImpl.java:74)
	at groovy.lang.GroovySystem.<clinit>(GroovySystem.java:36)
	... 29 more
@eerohele

This comment has been minimized.

Copy link

commented Nov 13, 2018

I encountered the same issue. The Xerces version Gradle uses interferes with the application I'm running with the Task Worker API. I haven't been able to figure out any way to work around the issue, either.

@ysb33r

This comment has been minimized.

Copy link
Contributor

commented Nov 24, 2018

I encountered the same issue. The Xerces version Gradle uses interferes with the application I'm running with the Task Worker API. I haven't been able to figure out any way to work around the issue, either.

@eerohele In the Asciidoctor plugin we have coded an option to run with javaexec. Best solution for the user for the user who can then select whether to use workers or javaexec.

@ysb33r

This comment has been minimized.

Copy link
Contributor

commented Nov 24, 2018

Here is another example where snakeyaml is leaked onto the classpath breaking anything in JRuby that needs the embedded snakeyaml instead: https://gist.github.com/ysb33r/00373e5ac8280367d895c4b61bf5b119

rmlekus added a commit to rmlekus/byte-buddy that referenced this issue Feb 20, 2019
Introducing a child first ClassLoader, for all non gradle and bytebud…
…dy API classes in order provide a work around for gradle Issue 3698 (Worker classpath should only contain necessary classes - gradle/gradle#3698)
rmlekus added a commit to rmlekus/byte-buddy that referenced this issue Feb 20, 2019
Introducing a child first ClassLoader, for all non gradle and bytebud…
…dy API classes in order provide a work around for gradle Issue 3698 (Worker classpath should only contain necessary classes - gradle/gradle#3698)
@rmlekus

This comment has been minimized.

Copy link

commented Feb 21, 2019

I encountered this issue when trying to instrument a build with a bytebuddy plugin depending on classes and methods introduced in google guava versions which are more recent than the version 17.0 currently used and injected by gradle to the class loaders used by the bytebuddy gradle plugin.

While the bytebuddy plugin works fine when used within a build managed by maven / the bytebuddy maven plugin, trying to re-produce the same build based on gradle /the bytebuddy gradle plugin resulted in class loading exceptions triggered by referencing the 17.0 guava version injected by gradle.

My local quick fix currently is to use a custom ClassLoader within a locally patched version of the bytebuddy gradle plugin. Getting a solution which allows to configure the correct classpath providing build-script dependencies from within build.gradle files would be really appreciated, though.

rmlekus added a commit to rmlekus/byte-buddy that referenced this issue Feb 21, 2019
Introducing a child first ClassLoader, for all non gradle and bytebud…
…dy API classes in order provide a work around for gradle Issue 3698 (Worker classpath should only contain necessary classes - gradle/gradle#3698)
rmlekus added a commit to rmlekus/byte-buddy that referenced this issue Feb 21, 2019
Introducing a child first ClassLoader, for all non gradle and bytebud…
…dy API classes in order provide a work around for gradle Issue 3698 (Worker classpath should only contain necessary classes - gradle/gradle#3698)
@ysb33r

This comment has been minimized.

Copy link
Contributor

commented Mar 4, 2019

As an additional point: If GradleRunner.withDebug(true) is used, even more unnecessary JARs are leaked into the worker classpath.

@big-guy

This comment has been minimized.

Copy link
Member

commented Jul 1, 2019

This will be in 5.6

@big-guy big-guy closed this Jul 1, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
9 participants
You can’t perform that action at this time.