Allow verbose mode to be programmatically changed #233
Labels
Milestone
Comments
|
I agree. We need to figure out the best way to enable this. This may be something we need to push up into AsciidoctorJ. As a workaround, you can create the following one-line script named verbose-mode.rb: $VERBOSE = truethen require it into the runtime using the |
|
@abelsromero @robertpanzer this is related to the logging improvements, but as I've realized in core, verbose mode is orthogonal to the logging severity level. |
|
Thank you for the workaround @mojavelinux. I wasn't sure if asciidoctorj had this capability, so I did not file an issue there, but I knew one would have to add to the asciidoctor extension to make this happen. |
|
@mojavelinux Should that not be OR did you mean |
ysb33r
added a commit
to ysb33r/asciidoctor-gradle-plugin
that referenced
this issue
Jun 8, 2018
- 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`. - Legavy code moved to 'org.asciidocotr.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. - 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. - 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. - 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`. - Using a worker approach for running Asciidoctor instances - Codenarc settings has been updated to find configuration from within subprojects. - Updated license headers. - Integration test for new AsciidoctorJ plugins utilising worker executors - AsciidoctorJPdf plugin has been added which adds a single `asciidoctorPdf` task and configures it accordingly to PDF behaviour. - 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).
ysb33r
added a commit
to ysb33r/asciidoctor-gradle-plugin
that referenced
this issue
Jun 8, 2018
- 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`. - Legavy code moved to 'org.asciidocotr.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. - 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. - 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`. - Using a worker approach for running Asciidoctor instances - Codenarc settings has been updated to find configuration from within subprojects. - Updated license headers. - Integration test for new AsciidoctorJ plugins utilising worker executors - AsciidoctorJPdf plugin has been added which adds a single `asciidoctorPdf` task and configures it accordingly to PDF behaviour. - 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).
ysb33r
added a commit
to ysb33r/asciidoctor-gradle-plugin
that referenced
this issue
Jun 8, 2018
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. 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`. - AsciidoctorTask differentitates between top-level sources, secondary sources and resources in order to have a better idea of being out-of-date. (asciidoctor#185) - Using a worker approach for running Asciidoctor instances. This addresses asciidoctor#220. - AsciidoctorJPdf plugin has been added which adds a single `asciidoctorPdf` task and configures it accordingly to PDF behaviour. - 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). Backwards compatibility and migration: - Legacy code moved to 'org.asciidocotr.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 8, 2018
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. 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`. - 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. This addresses asciidoctor#220. - AsciidoctorJPdf plugin has been added which adds a single `asciidoctorPdf` task and configures it accordingly to PDF behaviour. - 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 taks are supportd by integration tests and compatibility tests. (asciidoctor#180) 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 8, 2018
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. 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. This addresses asciidoctor#220. - AsciidoctorJPdf plugin has been added which adds a single `asciidoctorPdf` task and configures it accordingly to PDF behaviour. - 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 taks are supportd by integration tests and compatibility tests. (asciidoctor#180) 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 8, 2018
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. 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. - AsciidoctorJPdf plugin has been added which adds a single `asciidoctorPdf` task and configures it accordingly to PDF behaviour. - 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 taks are supportd by integration tests and compatibility tests. (asciidoctor#180) 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 8, 2018
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. 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. - AsciidoctorJPdf plugin has been added which adds a single `asciidoctorPdf` task and configures it accordingly to PDF behaviour. - 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 taks are supportd by integration tests and compatibility tests. (asciidoctor#180) 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.
This one. It's a local file, so whatever you need to do to get Gradle to find it. |
|
Got it.
…Sent from my Samsung device
-------- Original message --------
From: Dan Allen <notifications@github.com>
Date: 08/06/2018 18:15 (GMT+00:00)
To: asciidoctor/asciidoctor-gradle-plugin <asciidoctor-gradle-plugin@noreply.github.com>
Cc: "Schalk W. Cronjé" <ysb33r@gmail.com>, Comment <comment@noreply.github.com>
Subject: Re: [asciidoctor/asciidoctor-gradle-plugin] Allow verbose mode to be
programmatically changed (#233)
OR did you mean asciidoctor.requires project.file('verbose.rb') ?
This one. It's a local file, so whatever you need to do to get Gradle to find it.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.
{"@context":"http://schema.org","@type":"EmailMessage","potentialAction":{"@type":"ViewAction","target":"https://github.com/asciidoctor/asciidoctor-gradle-plugin/issues/233#issuecomment-395827338","url":"https://github.com/asciidoctor/asciidoctor-gradle-plugin/issues/233#issuecomment-395827338","name":"View Issue"},"description":"View this Issue on GitHub","publisher":{"@type":"Organization","name":"GitHub","url":"https://github.com"}}
{"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/asciidoctor/asciidoctor-gradle-plugin","title":"asciidoctor/asciidoctor-gradle-plugin","subtitle":"GitHub repository","main_image_url":"https://assets-cdn.github.com/images/email/message_cards/header.png","avatar_image_url":"https://assets-cdn.github.com/images/email/message_cards/avatar.png","action":{"name":"Open in GitHub","url":"https://github.com/asciidoctor/asciidoctor-gradle-plugin"}},"updates":{"snippets":[{"icon":"PERSON","message":"@mojavelinux in #233: \u003e OR did you mean asciidoctor.requires project.file('verbose.rb') ?\r\n\r\nThis one. It's a local file, so whatever you need to do to get Gradle to find it."}],"action":{"name":"View Issue","url":"#233 (comment)"}}}
{
"@type": "MessageCard",
"@context": "http://schema.org/extensions",
"hideOriginalBody": "false",
"originator": "AF6C5A86-E920-430C-9C59-A73278B5EFEB",
"title": "Re: [asciidoctor/asciidoctor-gradle-plugin] Allow verbose mode to be programmatically changed (#233)",
"sections": [
{
"text": "",
"activityTitle": "**Dan Allen**",
"activityImage": "https://assets-cdn.github.com/images/email/message_cards/avatar.png",
"activitySubtitle": "@mojavelinux",
"facts": [
]
}
],
"potentialAction": [
{
"name": "Add a comment",
"@type": "ActionCard",
"inputs": [
{
"isMultiLine": true,
"@type": "TextInput",
"id": "IssueComment",
"isRequired": false
}
],
"actions": [
{
"name": "Comment",
"@type": "HttpPOST",
"target": "https://api.github.com",
"body": "{\n\"commandName\": \"IssueComment\",\n\"repositoryFullName\": \"asciidoctor/asciidoctor-gradle-plugin\",\n\"issueId\": 233,\n\"IssueComment\": \"{{IssueComment.value}}\"\n}"
}
]
},
{
"name": "Close issue",
"@type": "HttpPOST",
"target": "https://api.github.com",
"body": "{\n\"commandName\": \"IssueClose\",\n\"repositoryFullName\": \"asciidoctor/asciidoctor-gradle-plugin\",\n\"issueId\": 233\n}"
},
{
"targets": [
{
"os": "default",
"uri": "#233 (comment)"
}
],
"@type": "OpenUri",
"name": "View on GitHub"
},
{
"name": "Unsubscribe",
"@type": "HttpPOST",
"target": "https://api.github.com",
"body": "{\n\"commandName\": \"MuteNotification\",\n\"threadId\": 334469898\n}"
}
],
"themeColor": "26292E"
}
|
ysb33r
added a commit
to ysb33r/asciidoctor-gradle-plugin
that referenced
this issue
Jun 13, 2018
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 24, 2018
General: - The version series is 2.0.0. It will be kept as alpha releases for a while. - Project restructured into multiple plugins using 'base' plugin model for Asciidoctor plugins. - Only support Gradle 4.0+. - Only support JDK8+. - For Gradle 4.5+ migration messages are controlled via `--warning-mode`. - For Gradle 4.0-4.4 migration messages are controlled via `--info`. - Additional text will be displayed on Gradle Plugin Portal for during alpha & beta releases. - Compatibility testing has been added and initialy against Gradle versions 4.0.2, 4.3.1 & 4.6. (For JDK10 only test against 4.7). - Some integration tests contain JRuby compatibility tests. Current test set is 1.7.27, 9.0.5.0/9.1.0.0, 9.1.17.0, 9.2.0.0. - JDK compatibility testing are done from JDK8 -> JDK10 (Travis) - Codenarc settings has been updated to find configuration from within subprojects. - Updated license headers to include 2018. - Integration tests utilises an offline Ivy repository (via Ivypot plugin) to reduce bandwith usage and test time. - AsciidoctorJ, GroovyDSL etc. versions are defined in code and read by the build script. This provides one point of definition and ensure that code can have appropriate default versions. - Test versions of JRuby and AsciidoctorJ is controlled via test fixtures. - Renamed AsciidoctorPlugin to AsciidoctorCompatiblityPlugin - Provide ability to either use AsciidoctorJ or AsciidoctorJS as the engine. (In this commit only AsciidoctorJ is implemented). - Test result logged in real-time when running on Appveyor. New generation AsciidoctorJ plugins and tasks: - New (JVM) AsciidoctorJ extension can be added to both project & tasks. Extension in task can be used to override global settings from the project extension. It takes into account some of the ideas @manuelprinz had for asciidoctor#231 for is much more extensive. - Extension has support for Asciidoctor verbose mode (asciidoctor#233). If `verboseMode` is set then a temporary file will be created and made part of Asciidoctor `requires`. - AsciidoctorJ v1.6.0-alpha.6 is the default version, but it is possible to set a 1.5.x version if required. - JRuby version can be controlled at both project and task level. If no version is specified at either level, the maximum of default the JRuby version that AsciidoctorJ depends on and a coded minimum safe version of JRuby, will be used. - AsciidoctorJExtension maintains it's own detached configuration which can be fine turned via resolution strategies for edge cases. - the `org.asciidoctor.jvm.base` plugin adds a dependency report specifically for the detached configuration. - GroovyDSL extensions are now registered either on the project extension or the task extensions. The extensions are only loaded within a worker instance. The asciidoctor task is unloaded at the end of the worker and with it the extensions. (asciidoctor#166) - AsciidoctorTask differentitates between top-level sources, secondary sources and resources in order to have a better idea of being out-of-date. (asciidoctor#185) - It is possible to control whether resources should be copied or not. This allows a build to better deal with a backend such as PDF, which do not need resources to be copied. - It is possible to perform the conversion from an intermediate working directory, which allows for a source directory to be kept pristine from intermediate artifacts generated from extensions such as ditaa. - Using a worker approach for running Asciidoctor instances. (asciidoctor#220) - Asciidoctor tasks can be configured to run AsciidoctorJ conversions in or out of process. Even when running in process AsciidoctorJ will be on an isolated classpath. - Tasks support parallel mode which will run each backend (or in the case of Epub, each output format) in a separate worker. This behevaiour can be turned off in which case only one Asciidoctor instance is used to run all conversions in sequence. - For cases where Gradle's idea of supplementing the classpath for workers do fail, there is a special `inProcess = JAVA_EXEC` that will run the conversion out of process, albeit less efficient than an out-of-process worker. - Due to Gradle API classpath leakage, builds with Gradle 4.0-4.2 will always run in `JAVA_EXEC` mode to prevent issues. - `AsciidoctorJPdf` plugin has been added which adds a single `asciidoctorPdf` task and configures it accordingly to PDF behaviour. It also sets a default version of the `asciidoctorj-pdf` dependency. - If the PDF backend is used and the JRuby version starts with '9.x' then place SnakeYaml v1.13 on the classpath. - Backends and separateOutputDirs are configured via an outputOptions closure or action. - `AsciidoctorJEpub` plugin has been added which adds a single `asciidoctorEpub` task and configures it accordingly to EPUB behaviour. It also sets a default version of the `asciidoctorj-epub` dependency. - Epub output formats can be set via the `ebookFormats` method. - Additional Kindlegen plugin which is invoked by EPUB for when the format is KF8. The plugin will bootstrap kindlegen on all supported platforms. - Work around gradle/gradle#3698 and Xerces API clash by running EPub conversions using `inProcess = JAVA_EXEC`. Also depend on `groovy-all` dependency rather than `localGroovy()` to see if that provides relief for the issue. - All methods on the new task classes that take closures as parameters now also have equivalent Action parameters (asciidoctor#236). - All new tasks are supportd by integration tests and compatibility tests. (asciidoctor#180) - Various tests use a combination of JRuby & AsciidoctorJ versions to test compatibility at the integration test level. Known issues: - Intermittent failures in tests related to bad file descriptor. Could be similar to asciidoctor/asciidoctorj#442. - EPUB3 + KF8 in one task (PendingFeature). Both formats in one task is currently failing. The exact failure message depends on which order (KF8+EPUB3 or EPUB3+KF8) the conversion takes place in. - KF8 conversions fails under Windows. Related to asciidoctor/asciidoctorj#659 & jruby/jruby#4943. - Does not work with JDK9 (but does with JDK10). Backwards compatibility and migration: - Legacy code moved to 'org.asciidoctor.gradle.compat' package, but get AsciidoctorTask in same package for compatibility purpose. - Renamed AsciidoctorPlugin to AsciidoctorCompatibilityPlugin. - Legacy plugin cannot be used with other Asciidoctor plugins within the same project. - Existing 1.5.x deprecated methods has been removed from legacy AsciidoctorTask.
ysb33r
added a commit
to ysb33r/asciidoctor-gradle-plugin
that referenced
this issue
Jun 25, 2018
General: - The version series is 2.0.0. It will be kept as alpha releases for a while. - Project restructured into multiple plugins using 'base' plugin model for Asciidoctor plugins. - Only support Gradle 4.0+. - Only support JDK8+. - For Gradle 4.5+ migration messages are controlled via `--warning-mode`. - For Gradle 4.0-4.4 migration messages are controlled via `--info`. - Additional text will be displayed on Gradle Plugin Portal for during alpha & beta releases. - Compatibility testing has been added and initialy against Gradle versions 4.0.2, 4.3.1 & 4.6. (For JDK10 only test against 4.7). - Some integration tests contain JRuby compatibility tests. Current test set is 1.7.27, 9.0.5.0/9.1.0.0, 9.1.17.0, 9.2.0.0. - JDK compatibility testing are done from JDK8 -> JDK10 (Travis) - Codenarc settings has been updated to find configuration from within subprojects. - Updated license headers to include 2018. - Integration tests utilises an offline Ivy repository (via Ivypot plugin) to reduce bandwith usage and test time. - AsciidoctorJ, GroovyDSL etc. versions are defined in code and read by the build script. This provides one point of definition and ensure that code can have appropriate default versions. - Test versions of JRuby and AsciidoctorJ is controlled via test fixtures. - Renamed AsciidoctorPlugin to AsciidoctorCompatiblityPlugin - Provide ability to either use AsciidoctorJ or AsciidoctorJS as the engine. (In this commit only AsciidoctorJ is implemented). - Test result logged in real-time when running on Appveyor. New generation AsciidoctorJ plugins and tasks: - New (JVM) AsciidoctorJ extension can be added to both project & tasks. Extension in task can be used to override global settings from the project extension. It takes into account some of the ideas @manuelprinz had for asciidoctor#231 for is much more extensive. - Extension has support for Asciidoctor verbose mode (asciidoctor#233). If `verboseMode` is set then a temporary file will be created and made part of Asciidoctor `requires`. - AsciidoctorJ v1.6.0-alpha.6 is the default version, but it is possible to set a 1.5.x version if required. - JRuby version can be controlled at both project and task level. If no version is specified at either level, the maximum of default the JRuby version that AsciidoctorJ depends on and a coded minimum safe version of JRuby, will be used. - AsciidoctorJExtension maintains it's own detached configuration which can be fine turned via resolution strategies for edge cases. - the `org.asciidoctor.jvm.base` plugin adds a dependency report specifically for the detached configuration. - GroovyDSL extensions are now registered either on the project extension or the task extensions. The extensions are only loaded within a worker instance. The asciidoctor task is unloaded at the end of the worker and with it the extensions. (asciidoctor#166) - AsciidoctorTask differentitates between top-level sources, secondary sources and resources in order to have a better idea of being out-of-date. (asciidoctor#185) - It is possible to control whether resources should be copied or not. This allows a build to better deal with a backend such as PDF, which do not need resources to be copied. - It is possible to perform the conversion from an intermediate working directory, which allows for a source directory to be kept pristine from intermediate artifacts generated from extensions such as ditaa. - Using a worker approach for running Asciidoctor instances. (asciidoctor#220) - Asciidoctor tasks can be configured to run AsciidoctorJ conversions in or out of process. Even when running in process AsciidoctorJ will be on an isolated classpath. - Tasks support parallel mode which will run each backend (or in the case of Epub, each output format) in a separate worker. This behevaiour can be turned off in which case only one Asciidoctor instance is used to run all conversions in sequence. - For cases where Gradle's idea of supplementing the classpath for workers do fail, there is a special `inProcess = JAVA_EXEC` that will run the conversion out of process, albeit less efficient than an out-of-process worker. - Due to Gradle API classpath leakage, builds with Gradle 4.0-4.2 will always run in `JAVA_EXEC` mode to prevent issues. - `AsciidoctorJPdf` plugin has been added which adds a single `asciidoctorPdf` task and configures it accordingly to PDF behaviour. It also sets a default version of the `asciidoctorj-pdf` dependency. - If the PDF backend is used and the JRuby version starts with '9.x' then place SnakeYaml v1.13 on the classpath. - Backends and separateOutputDirs are configured via an outputOptions closure or action. - `AsciidoctorJEpub` plugin has been added which adds a single `asciidoctorEpub` task and configures it accordingly to EPUB behaviour. It also sets a default version of the `asciidoctorj-epub` dependency. - Epub output formats can be set via the `ebookFormats` method. - Additional Kindlegen plugin which is invoked by EPUB for when the format is KF8. The plugin will bootstrap kindlegen on all supported platforms. - Work around gradle/gradle#3698 and Xerces API clash by running EPub conversions using `inProcess = JAVA_EXEC`. Also depend on `groovy-all` dependency rather than `localGroovy()` to see if that provides relief for the issue. - All methods on the new task classes that take closures as parameters now also have equivalent Action parameters (asciidoctor#236). - All new tasks are supportd by integration tests and compatibility tests. (asciidoctor#180) - Various tests use a combination of JRuby & AsciidoctorJ versions to test compatibility at the integration test level. Known issues: - Intermittent failures in tests related to bad file descriptor. Could be similar to asciidoctor/asciidoctorj#442. - EPUB3 + KF8 in one task (PendingFeature). Both formats in one task is currently failing. The exact failure message depends on which order (KF8+EPUB3 or EPUB3+KF8) the conversion takes place in. - KF8 conversions fails under Windows. Related to asciidoctor/asciidoctorj#659 & jruby/jruby#4943. - Does not work with JDK9 (but does with JDK10). Backwards compatibility and migration: - Legacy code moved to 'org.asciidoctor.gradle.compat' package, but get AsciidoctorTask in same package for compatibility purpose. - Renamed AsciidoctorPlugin to AsciidoctorCompatibilityPlugin. - Legacy plugin cannot be used with other Asciidoctor plugins within the same project. - Existing 1.5.x deprecated methods has been removed from legacy AsciidoctorTask.
ysb33r
added a commit
to ysb33r/asciidoctor-gradle-plugin
that referenced
this issue
Jun 25, 2018
General: - The version series is 2.0.0. It will be kept as alpha releases for a while. - Project restructured into multiple plugins using 'base' plugin model for Asciidoctor plugins. - Only support Gradle 4.0+. - Only support JDK8+. - For Gradle 4.5+ migration messages are controlled via `--warning-mode`. - For Gradle 4.0-4.4 migration messages are controlled via `--info`. - Additional text will be displayed on Gradle Plugin Portal for during alpha & beta releases. - Compatibility testing has been added and initialy against Gradle versions 4.0.2, 4.3.1 & 4.6. (For JDK10 only test against 4.7). - Some integration tests contain JRuby compatibility tests. Current test set is 1.7.27, 9.0.5.0/9.1.0.0, 9.1.17.0, 9.2.0.0. - JDK compatibility testing are done from JDK8 -> JDK10 (Travis) - Codenarc settings has been updated to find configuration from within subprojects. - Updated license headers to include 2018. - Integration tests utilises an offline Ivy repository (via Ivypot plugin) to reduce bandwith usage and test time. - AsciidoctorJ, GroovyDSL etc. versions are defined in code and read by the build script. This provides one point of definition and ensure that code can have appropriate default versions. - Test versions of JRuby and AsciidoctorJ is controlled via test fixtures. - Renamed AsciidoctorPlugin to AsciidoctorCompatiblityPlugin - Provide ability to either use AsciidoctorJ or AsciidoctorJS as the engine. (In this commit only AsciidoctorJ is implemented). - Test result logged in real-time when running on Appveyor. New generation AsciidoctorJ plugins and tasks: - New (JVM) AsciidoctorJ extension can be added to both project & tasks. Extension in task can be used to override global settings from the project extension. It takes into account some of the ideas @manuelprinz had for asciidoctor#231 for is much more extensive. - Extension has support for Asciidoctor verbose mode (asciidoctor#233). If `verboseMode` is set then a temporary file will be created and made part of Asciidoctor `requires`. - AsciidoctorJ v1.6.0-alpha.6 is the default version, but it is possible to set a 1.5.x version if required. - JRuby version can be controlled at both project and task level. If no version is specified at either level, the maximum of default the JRuby version that AsciidoctorJ depends on and a coded minimum safe version of JRuby, will be used. - AsciidoctorJExtension maintains it's own detached configuration which can be fine turned via resolution strategies for edge cases. - the `org.asciidoctor.jvm.base` plugin adds a dependency report specifically for the detached configuration. - GroovyDSL extensions are now registered either on the project extension or the task extensions. The extensions are only loaded within a worker instance. The asciidoctor task is unloaded at the end of the worker and with it the extensions. (asciidoctor#166) - AsciidoctorTask differentitates between top-level sources, secondary sources and resources in order to have a better idea of being out-of-date. (asciidoctor#185) - It is possible to control whether resources should be copied or not. This allows a build to better deal with a backend such as PDF, which do not need resources to be copied. - It is possible to perform the conversion from an intermediate working directory, which allows for a source directory to be kept pristine from intermediate artifacts generated from extensions such as ditaa. - Using a worker approach for running Asciidoctor instances. (asciidoctor#220) - Asciidoctor tasks can be configured to run AsciidoctorJ conversions in or out of process. Even when running in process AsciidoctorJ will be on an isolated classpath. - Tasks support parallel mode which will run each backend (or in the case of Epub, each output format) in a separate worker. This behevaiour can be turned off in which case only one Asciidoctor instance is used to run all conversions in sequence. - For cases where Gradle's idea of supplementing the classpath for workers do fail, there is a special `inProcess = JAVA_EXEC` that will run the conversion out of process, albeit less efficient than an out-of-process worker. - Due to Gradle API classpath leakage, builds with Gradle 4.0-4.2 will always run in `JAVA_EXEC` mode to prevent issues. - `AsciidoctorJPdf` plugin has been added which adds a single `asciidoctorPdf` task and configures it accordingly to PDF behaviour. It also sets a default version of the `asciidoctorj-pdf` dependency. - If the PDF backend is used and the JRuby version starts with '9.x' then place SnakeYaml v1.13 on the classpath. - Backends and separateOutputDirs are configured via an outputOptions closure or action. - `AsciidoctorJEpub` plugin has been added which adds a single `asciidoctorEpub` task and configures it accordingly to EPUB behaviour. It also sets a default version of the `asciidoctorj-epub` dependency. - Epub output formats can be set via the `ebookFormats` method. - Additional Kindlegen plugin which is invoked by EPUB for when the format is KF8. The plugin will bootstrap kindlegen on all supported platforms. - Work around gradle/gradle#3698 and Xerces API clash by running EPub conversions using `inProcess = JAVA_EXEC`. Also depend on `groovy-all` dependency rather than `localGroovy()` to see if that provides relief for the issue. - Asciidoctorj-diagram supprot is in-built. Just specify the version on the extension and the artifact will be added to the classpatj. The necessary addition will be made to `requires` as well. - All methods on the new task classes that take closures as parameters now also have equivalent Action parameters (asciidoctor#236). - All new tasks are supportd by integration tests and compatibility tests. (asciidoctor#180) - Various tests use a combination of JRuby & AsciidoctorJ versions to test compatibility at the integration test level. Known issues: - Intermittent failures in tests related to bad file descriptor. Could be similar to asciidoctor/asciidoctorj#442. - EPUB3 + KF8 in one task (PendingFeature). Both formats in one task is currently failing. The exact failure message depends on which order (KF8+EPUB3 or EPUB3+KF8) the conversion takes place in. - KF8 conversions fails under Windows. Related to asciidoctor/asciidoctorj#659 & jruby/jruby#4943. - Does not work with JDK9 (but does with JDK10). Backwards compatibility and migration: - Legacy code moved to 'org.asciidoctor.gradle.compat' package, but get AsciidoctorTask in same package for compatibility purpose. - Renamed AsciidoctorPlugin to AsciidoctorCompatibilityPlugin. - Legacy plugin cannot be used with other Asciidoctor plugins within the same project. - Existing 1.5.x deprecated methods has been removed from legacy AsciidoctorTask. - asciidoctor#238 has been forard-ported to check that the same issue do not occur when using the compatibility task.
ysb33r
added a commit
to ysb33r/asciidoctor-gradle-plugin
that referenced
this issue
Jun 25, 2018
General: - The version series is 2.0.0. It will be kept as alpha releases for a while. - Project restructured into multiple plugins using 'base' plugin model for Asciidoctor plugins. - Only support Gradle 4.0+. - Only support JDK8+. - For Gradle 4.5+ migration messages are controlled via `--warning-mode`. - For Gradle 4.0-4.4 migration messages are controlled via `--info`. - Additional text will be displayed on Gradle Plugin Portal for during alpha & beta releases. - Compatibility testing has been added and initialy against Gradle versions 4.0.2, 4.3.1 & 4.6. (For JDK10 only test against 4.7). - Some integration tests contain JRuby compatibility tests. Current test set is 1.7.27, 9.0.5.0/9.1.0.0, 9.1.17.0, 9.2.0.0. - JDK compatibility testing are done from JDK8 -> JDK10 (Travis) - Codenarc settings has been updated to find configuration from within subprojects. - Updated license headers to include 2018. - Integration tests utilises an offline Ivy repository (via Ivypot plugin) to reduce bandwith usage and test time. - AsciidoctorJ, GroovyDSL etc. versions are defined in code and read by the build script. This provides one point of definition and ensure that code can have appropriate default versions. - Test versions of JRuby and AsciidoctorJ is controlled via test fixtures. - Renamed AsciidoctorPlugin to AsciidoctorCompatiblityPlugin - Provide ability to either use AsciidoctorJ or AsciidoctorJS as the engine. (In this commit only AsciidoctorJ is implemented). - Test result logged in real-time when running on Appveyor. New generation AsciidoctorJ plugins and tasks: - New (JVM) AsciidoctorJ extension can be added to both project & tasks. Extension in task can be used to override global settings from the project extension. It takes into account some of the ideas @manuelprinz had for asciidoctor#231 for is much more extensive. - Extension has support for Asciidoctor verbose mode (asciidoctor#233). If `verboseMode` is set then a temporary file will be created and made part of Asciidoctor `requires`. - AsciidoctorJ v1.6.0-alpha.6 is the default version, but it is possible to set a 1.5.x version if required. - JRuby version can be controlled at both project and task level. If no version is specified at either level, the maximum of default the JRuby version that AsciidoctorJ depends on and a coded minimum safe version of JRuby, will be used. - AsciidoctorJExtension maintains it's own detached configuration which can be fine turned via resolution strategies for edge cases. - the `org.asciidoctor.jvm.base` plugin adds a dependency report specifically for the detached configuration. - GroovyDSL extensions are now registered either on the project extension or the task extensions. The extensions are only loaded within a worker instance. The asciidoctor task is unloaded at the end of the worker and with it the extensions. (asciidoctor#166) - AsciidoctorTask differentitates between top-level sources, secondary sources and resources in order to have a better idea of being out-of-date. (asciidoctor#185) - It is possible to control whether resources should be copied or not. This allows a build to better deal with a backend such as PDF, which do not need resources to be copied. - It is possible to perform the conversion from an intermediate working directory, which allows for a source directory to be kept pristine from intermediate artifacts generated from extensions such as ditaa. - Using a worker approach for running Asciidoctor instances. (asciidoctor#220) - Asciidoctor tasks can be configured to run AsciidoctorJ conversions in or out of process. Even when running in process AsciidoctorJ will be on an isolated classpath. - Tasks support parallel mode which will run each backend (or in the case of Epub, each output format) in a separate worker. This behevaiour can be turned off in which case only one Asciidoctor instance is used to run all conversions in sequence. - For cases where Gradle's idea of supplementing the classpath for workers do fail, there is a special `inProcess = JAVA_EXEC` that will run the conversion out of process, albeit less efficient than an out-of-process worker. - Due to Gradle API classpath leakage, builds with Gradle 4.0-4.2 will always run in `JAVA_EXEC` mode to prevent issues. - `AsciidoctorJPdf` plugin has been added which adds a single `asciidoctorPdf` task and configures it accordingly to PDF behaviour. It also sets a default version of the `asciidoctorj-pdf` dependency. - If the PDF backend is used and the JRuby version starts with '9.x' then place SnakeYaml v1.13 on the classpath. - Backends and separateOutputDirs are configured via an outputOptions closure or action. - `AsciidoctorJEpub` plugin has been added which adds a single `asciidoctorEpub` task and configures it accordingly to EPUB behaviour. It also sets a default version of the `asciidoctorj-epub` dependency. - Epub output formats can be set via the `ebookFormats` method. - Additional Kindlegen plugin which is invoked by EPUB for when the format is KF8. The plugin will bootstrap kindlegen on all supported platforms. - Work around gradle/gradle#3698 and Xerces API clash by running EPub conversions using `inProcess = JAVA_EXEC`. Also depend on `groovy-all` dependency rather than `localGroovy()` to see if that provides relief for the issue. - Asciidoctorj-diagram supprot is in-built. Just specify the version on the extension and the artifact will be added to the classpatj. The necessary addition will be made to `requires` as well. - All methods on the new task classes that take closures as parameters now also have equivalent Action parameters (asciidoctor#236). - All new tasks are supportd by integration tests and compatibility tests. (asciidoctor#180) - Various tests use a combination of JRuby & AsciidoctorJ versions to test compatibility at the integration test level. Known issues: - Intermittent failures in tests related to bad file descriptor. Could be similar to asciidoctor/asciidoctorj#442. - EPUB3 + KF8 in one task (PendingFeature). Both formats in one task is currently failing. The exact failure message depends on which order (KF8+EPUB3 or EPUB3+KF8) the conversion takes place in. - KF8 conversions fails under Windows. Related to asciidoctor/asciidoctorj#659 & jruby/jruby#4943. - Does not work with JDK9 (but does with JDK10). Backwards compatibility and migration: - Legacy code moved to 'org.asciidoctor.gradle.compat' package, but get AsciidoctorTask in same package for compatibility purpose. - Renamed AsciidoctorPlugin to AsciidoctorCompatibilityPlugin. - Legacy plugin cannot be used with other Asciidoctor plugins within the same project. - Existing 1.5.x deprecated methods has been removed from legacy AsciidoctorTask. - asciidoctor#238 has been forard-ported to check that the same issue do not occur when using the compatibility task.
ysb33r
added a commit
to ysb33r/asciidoctor-gradle-plugin
that referenced
this issue
Jun 26, 2018
General: - The version series is 2.0.0. It will be kept as alpha releases for a while. - Project restructured into multiple plugins using 'base' plugin model for Asciidoctor plugins. - Only support Gradle 4.0+. - Only support JDK8+. - For Gradle 4.5+ migration messages are controlled via `--warning-mode`. - For Gradle 4.0-4.4 migration messages are controlled via `--info`. - Additional text will be displayed on Gradle Plugin Portal for during alpha & beta releases. - Compatibility testing has been added and initialy against Gradle versions 4.0.2, 4.3.1 & 4.6. (For JDK10 only test against 4.7). - Some integration tests contain JRuby compatibility tests. Current test set is 1.7.27, 9.0.5.0/9.1.0.0, 9.1.17.0, 9.2.0.0. - JDK compatibility testing are done from JDK8 -> JDK10 (Travis) - Codenarc settings has been updated to find configuration from within subprojects. - Updated license headers to include 2018. - Integration tests utilises an offline Ivy repository (via Ivypot plugin) to reduce bandwith usage and test time. - AsciidoctorJ, GroovyDSL etc. versions are defined in code and read by the build script. This provides one point of definition and ensure that code can have appropriate default versions. - Test versions of JRuby and AsciidoctorJ is controlled via test fixtures. - Renamed AsciidoctorPlugin to AsciidoctorCompatiblityPlugin - Provide ability to either use AsciidoctorJ or AsciidoctorJS as the engine. (In this commit only AsciidoctorJ is implemented). - Test result logged in real-time when running on Appveyor. New generation AsciidoctorJ plugins and tasks: - New (JVM) AsciidoctorJ extension can be added to both project & tasks. Extension in task can be used to override global settings from the project extension. It takes into account some of the ideas @manuelprinz had for asciidoctor#231 for is much more extensive. - Extension has support for Asciidoctor verbose mode (asciidoctor#233). If `verboseMode` is set then a temporary file will be created and made part of Asciidoctor `requires`. - AsciidoctorJ v1.6.0-alpha.6 is the default version, but it is possible to set a 1.5.x version if required. - JRuby version can be controlled at both project and task level. If no version is specified at either level, the maximum of default the JRuby version that AsciidoctorJ depends on and a coded minimum safe version of JRuby, will be used. - AsciidoctorJExtension maintains it's own detached configuration which can be fine turned via resolution strategies for edge cases. - the `org.asciidoctor.jvm.base` plugin adds a dependency report specifically for the detached configuration. - GroovyDSL extensions are now registered either on the project extension or the task extensions. The extensions are only loaded within a worker instance. The asciidoctor task is unloaded at the end of the worker and with it the extensions. (asciidoctor#166) - AsciidoctorTask differentitates between top-level sources, secondary sources and resources in order to have a better idea of being out-of-date. (asciidoctor#185) - It is possible to control whether resources should be copied or not. This allows a build to better deal with a backend such as PDF, which do not need resources to be copied. - It is possible to perform the conversion from an intermediate working directory, which allows for a source directory to be kept pristine from intermediate artifacts generated from extensions such as ditaa. - Using a worker approach for running Asciidoctor instances. (asciidoctor#220) - Asciidoctor tasks can be configured to run AsciidoctorJ conversions in or out of process. Even when running in process AsciidoctorJ will be on an isolated classpath. - Tasks support parallel mode which will run each backend (or in the case of Epub, each output format) in a separate worker. This behevaiour can be turned off in which case only one Asciidoctor instance is used to run all conversions in sequence. - For cases where Gradle's idea of supplementing the classpath for workers do fail, there is a special `inProcess = JAVA_EXEC` that will run the conversion out of process, albeit less efficient than an out-of-process worker. - Due to Gradle API classpath leakage, builds with Gradle 4.0-4.2 will always run in `JAVA_EXEC` mode to prevent issues. - `AsciidoctorJPdf` plugin has been added which adds a single `asciidoctorPdf` task and configures it accordingly to PDF behaviour. It also sets a default version of the `asciidoctorj-pdf` dependency. - If the PDF backend is used and the JRuby version starts with '9.x' then place SnakeYaml v1.13 on the classpath. - Backends and separateOutputDirs are configured via an outputOptions closure or action. - `AsciidoctorJEpub` plugin has been added which adds a single `asciidoctorEpub` task and configures it accordingly to EPUB behaviour. It also sets a default version of the `asciidoctorj-epub` dependency. - Epub output formats can be set via the `ebookFormats` method. - Additional Kindlegen plugin which is invoked by EPUB for when the format is KF8. The plugin will bootstrap kindlegen on all supported platforms. - Work around gradle/gradle#3698 and Xerces API clash by running EPub conversions using `inProcess = JAVA_EXEC`. Also depend on `groovy-all` dependency rather than `localGroovy()` to see if that provides relief for the issue. - Asciidoctorj-diagram supprot is in-built. Just specify the version on the extension and the artifact will be added to the classpatj. The necessary addition will be made to `requires` as well. - All methods on the new task classes that take closures as parameters now also have equivalent Action parameters (asciidoctor#236). - All new tasks are supportd by integration tests and compatibility tests. (asciidoctor#180) - Various tests use a combination of JRuby & AsciidoctorJ versions to test compatibility at the integration test level. Known issues: - Intermittent failures in tests related to bad file descriptor. Could be similar to asciidoctor/asciidoctorj#442. - EPUB3 + KF8 in one task (PendingFeature). Both formats in one task is currently failing. The exact failure message depends on which order (KF8+EPUB3 or EPUB3+KF8) the conversion takes place in. - KF8 conversions fails under Windows. Related to asciidoctor/asciidoctorj#659 & jruby/jruby#4943. - Does not work with JDK9 (but does with JDK10). Backwards compatibility and migration: - Legacy code moved to 'org.asciidoctor.gradle.compat' package, but get AsciidoctorTask in same package for compatibility purpose. - Renamed AsciidoctorPlugin to AsciidoctorCompatibilityPlugin. - Legacy plugin cannot be used with other Asciidoctor plugins within the same project. - Existing 1.5.x deprecated methods has been removed from legacy AsciidoctorTask. - asciidoctor#238 has been forard-ported to check that the same issue do not occur when using the compatibility task.
ysb33r
added a commit
to ysb33r/asciidoctor-gradle-plugin
that referenced
this issue
Jun 27, 2018
General: - The version series is 2.0.0. It will be kept as alpha releases for a while. - Project restructured into multiple plugins using 'base' plugin model for Asciidoctor plugins. - Only support Gradle 4.0+. - Only support JDK8+. - For Gradle 4.5+ migration messages are controlled via `--warning-mode`. - For Gradle 4.0-4.4 migration messages are controlled via `--info`. - Additional text will be displayed on Gradle Plugin Portal for during alpha & beta releases. - Compatibility testing has been added and initialy against Gradle versions 4.0.2, 4.3.1 & 4.6. (For JDK10 only test against 4.7). - Some integration tests contain JRuby compatibility tests. Current test set is 1.7.27, 9.0.5.0/9.1.0.0, 9.1.17.0, 9.2.0.0. - JDK compatibility testing are done from JDK8 -> JDK10 (Travis) - Codenarc settings has been updated to find configuration from within subprojects. - Updated license headers to include 2018. - Integration tests utilises an offline Ivy repository (via Ivypot plugin) to reduce bandwith usage and test time. - AsciidoctorJ, GroovyDSL etc. versions are defined in code and read by the build script. This provides one point of definition and ensure that code can have appropriate default versions. - Test versions of JRuby and AsciidoctorJ is controlled via test fixtures. - Renamed AsciidoctorPlugin to AsciidoctorCompatiblityPlugin - Provide ability to either use AsciidoctorJ or AsciidoctorJS as the engine. (In this commit only AsciidoctorJ is implemented). - Test result logged in real-time when running on Appveyor. New generation AsciidoctorJ plugins and tasks: - New (JVM) AsciidoctorJ extension can be added to both project & tasks. Extension in task can be used to override global settings from the project extension. It takes into account some of the ideas @manuelprinz had for asciidoctor#231 for is much more extensive. - Extension has support for Asciidoctor verbose mode (asciidoctor#233). If `verboseMode` is set then a temporary file will be created and made part of Asciidoctor `requires`. - AsciidoctorJ v1.6.0-alpha.6 is the default version, but it is possible to set a 1.5.x version if required. - JRuby version can be controlled at both project and task level. If no version is specified at either level, the maximum of default the JRuby version that AsciidoctorJ depends on and a coded minimum safe version of JRuby, will be used. - AsciidoctorJExtension maintains it's own detached configuration which can be fine turned via resolution strategies for edge cases. - the `org.asciidoctor.jvm.base` plugin adds a dependency report specifically for the detached configuration. - GroovyDSL extensions are now registered either on the project extension or the task extensions. The extensions are only loaded within a worker instance. The asciidoctor task is unloaded at the end of the worker and with it the extensions. (asciidoctor#166) - AsciidoctorTask differentitates between top-level sources, secondary sources and resources in order to have a better idea of being out-of-date. (asciidoctor#185) - It is possible to control whether resources should be copied or not. This allows a build to better deal with a backend such as PDF, which do not need resources to be copied. - It is possible to perform the conversion from an intermediate working directory, which allows for a source directory to be kept pristine from intermediate artifacts generated from extensions such as ditaa. - Using a worker approach for running Asciidoctor instances. (asciidoctor#220) - Asciidoctor tasks can be configured to run AsciidoctorJ conversions in or out of process. Even when running in process AsciidoctorJ will be on an isolated classpath. - Tasks support parallel mode which will run each backend (or in the case of Epub, each output format) in a separate worker. This behevaiour can be turned off in which case only one Asciidoctor instance is used to run all conversions in sequence. - For cases where Gradle's idea of supplementing the classpath for workers do fail, there is a special `inProcess = JAVA_EXEC` that will run the conversion out of process, albeit less efficient than an out-of-process worker. - Due to Gradle API classpath leakage, builds with Gradle 4.0-4.2 will always run in `JAVA_EXEC` mode to prevent issues. - `AsciidoctorJPdf` plugin has been added which adds a single `asciidoctorPdf` task and configures it accordingly to PDF behaviour. It also sets a default version of the `asciidoctorj-pdf` dependency. - If the PDF backend is used and the JRuby version starts with '9.x' then place SnakeYaml v1.13 on the classpath. - Backends and separateOutputDirs are configured via an outputOptions closure or action. - `AsciidoctorJEpub` plugin has been added which adds a single `asciidoctorEpub` task and configures it accordingly to EPUB behaviour. It also sets a default version of the `asciidoctorj-epub` dependency. - Epub output formats can be set via the `ebookFormats` method. - Additional Kindlegen plugin which is invoked by EPUB for when the format is KF8. The plugin will bootstrap kindlegen on all supported platforms. - Work around gradle/gradle#3698 and Xerces API clash by running EPub conversions using `inProcess = JAVA_EXEC`. Also depend on `groovy-all` dependency rather than `localGroovy()` to see if that provides relief for the issue. - Asciidoctorj-diagram supprot is in-built. Just specify the version on the extension and the artifact will be added to the classpatj. The necessary addition will be made to `requires` as well. - All methods on the new task classes that take closures as parameters now also have equivalent Action parameters (asciidoctor#236). - All new tasks are supportd by integration tests and compatibility tests. (asciidoctor#180) - Various tests use a combination of JRuby & AsciidoctorJ versions to test compatibility at the integration test level. Known issues: - Intermittent failures in tests related to bad file descriptor. Could be similar to asciidoctor/asciidoctorj#442. - EPUB3 + KF8 in one task (PendingFeature). Both formats in one task is currently failing. The exact failure message depends on which order (KF8+EPUB3 or EPUB3+KF8) the conversion takes place in. - KF8 conversions fails under Windows. Related to asciidoctor/asciidoctorj#659 & jruby/jruby#4943. - Does not work with JDK9 (but does with JDK10). Backwards compatibility and migration: - Legacy code moved to 'org.asciidoctor.gradle.compat' package, but get AsciidoctorTask in same package for compatibility purpose. - Renamed AsciidoctorPlugin to AsciidoctorCompatibilityPlugin. - Legacy plugin cannot be used with other Asciidoctor plugins within the same project. - Existing 1.5.x deprecated methods has been removed from legacy AsciidoctorTask. - asciidoctor#238 has been forard-ported to check that the same issue do not occur when using the compatibility task.
ysb33r
added a commit
to ysb33r/asciidoctor-gradle-plugin
that referenced
this issue
Jun 27, 2018
General: - The version series is 2.0.0. It will be kept as alpha releases for a while. - Project restructured into multiple plugins using 'base' plugin model for Asciidoctor plugins. - Only support Gradle 4.0+. - Only support JDK8+. - For Gradle 4.5+ migration messages are controlled via `--warning-mode`. - For Gradle 4.0-4.4 migration messages are controlled via `--info`. - Additional text will be displayed on Gradle Plugin Portal for during alpha & beta releases. - Compatibility testing has been added and initialy against Gradle versions 4.0.2, 4.3.1 & 4.6. (For JDK10 only test against 4.7). - Some integration tests contain JRuby compatibility tests. Current test set is 1.7.27, 9.0.5.0/9.1.0.0, 9.1.17.0, 9.2.0.0. - JDK compatibility testing are done from JDK8 -> JDK10 (Travis) - Codenarc settings has been updated to find configuration from within subprojects. - Updated license headers to include 2018. - Integration tests utilises an offline Ivy repository (via Ivypot plugin) to reduce bandwith usage and test time. - AsciidoctorJ, GroovyDSL etc. versions are defined in code and read by the build script. This provides one point of definition and ensure that code can have appropriate default versions. - Test versions of JRuby and AsciidoctorJ is controlled via test fixtures. - Renamed AsciidoctorPlugin to AsciidoctorCompatiblityPlugin - Provide ability to either use AsciidoctorJ or AsciidoctorJS as the engine. (In this commit only AsciidoctorJ is implemented). - Test result logged in real-time when running on Appveyor. New generation AsciidoctorJ plugins and tasks: - New (JVM) AsciidoctorJ extension can be added to both project & tasks. Extension in task can be used to override global settings from the project extension. It takes into account some of the ideas @manuelprinz had for asciidoctor#231 for is much more extensive. - Extension has support for Asciidoctor verbose mode (asciidoctor#233). If `verboseMode` is set then a temporary file will be created and made part of Asciidoctor `requires`. - AsciidoctorJ v1.6.0-alpha.6 is the default version, but it is possible to set a 1.5.x version if required. - JRuby version can be controlled at both project and task level. If no version is specified at either level, the maximum of default the JRuby version that AsciidoctorJ depends on and a coded minimum safe version of JRuby, will be used. - AsciidoctorJExtension maintains it's own detached configuration which can be fine turned via resolution strategies for edge cases. - the `org.asciidoctor.jvm.base` plugin adds a dependency report specifically for the detached configuration. - GroovyDSL extensions are now registered either on the project extension or the task extensions. The extensions are only loaded within a worker instance. The asciidoctor task is unloaded at the end of the worker and with it the extensions. (asciidoctor#166) - AsciidoctorTask differentitates between top-level sources, secondary sources and resources in order to have a better idea of being out-of-date. (asciidoctor#185) - It is possible to control whether resources should be copied or not. This allows a build to better deal with a backend such as PDF, which do not need resources to be copied. - It is possible to perform the conversion from an intermediate working directory, which allows for a source directory to be kept pristine from intermediate artifacts generated from extensions such as ditaa. - Using a worker approach for running Asciidoctor instances. (asciidoctor#220) - Asciidoctor tasks can be configured to run AsciidoctorJ conversions in or out of process. Even when running in process AsciidoctorJ will be on an isolated classpath. - Tasks support parallel mode which will run each backend (or in the case of Epub, each output format) in a separate worker. This behevaiour can be turned off in which case only one Asciidoctor instance is used to run all conversions in sequence. - For cases where Gradle's idea of supplementing the classpath for workers do fail, there is a special `inProcess = JAVA_EXEC` that will run the conversion out of process, albeit less efficient than an out-of-process worker. - Due to Gradle API classpath leakage, builds with Gradle 4.0-4.2 will always run in `JAVA_EXEC` mode to prevent issues. - `AsciidoctorJPdf` plugin has been added which adds a single `asciidoctorPdf` task and configures it accordingly to PDF behaviour. It also sets a default version of the `asciidoctorj-pdf` dependency. - If the PDF backend is used and the JRuby version starts with '9.x' then place SnakeYaml v1.13 on the classpath. - Backends and separateOutputDirs are configured via an outputOptions closure or action. - `AsciidoctorJEpub` plugin has been added which adds a single `asciidoctorEpub` task and configures it accordingly to EPUB behaviour. It also sets a default version of the `asciidoctorj-epub` dependency. - Epub output formats can be set via the `ebookFormats` method. - Additional Kindlegen plugin which is invoked by EPUB for when the format is KF8. The plugin will bootstrap kindlegen on all supported platforms. - Work around gradle/gradle#3698 and Xerces API clash by running EPub conversions using `inProcess = JAVA_EXEC`. Also depend on `groovy-all` dependency rather than `localGroovy()` to see if that provides relief for the issue. - Asciidoctorj-diagram supprot is in-built. Just specify the version on the extension and the artifact will be added to the classpatj. The necessary addition will be made to `requires` as well. - All methods on the new task classes that take closures as parameters now also have equivalent Action parameters (asciidoctor#236). - All new tasks are supportd by integration tests and compatibility tests. (asciidoctor#180) - Various tests use a combination of JRuby & AsciidoctorJ versions to test compatibility at the integration test level. Known issues: - Intermittent failures in tests related to bad file descriptor. Could be similar to asciidoctor/asciidoctorj#442. - EPUB3 + KF8 in one task (PendingFeature). Both formats in one task is currently failing. The exact failure message depends on which order (KF8+EPUB3 or EPUB3+KF8) the conversion takes place in. - KF8 conversions fails under Windows. Related to asciidoctor/asciidoctorj#659 & jruby/jruby#4943. - Does not work with JDK9 (but does with JDK10). Backwards compatibility and migration: - Legacy code moved to 'org.asciidoctor.gradle.compat' package, but get AsciidoctorTask in same package for compatibility purpose. - Renamed AsciidoctorPlugin to AsciidoctorCompatibilityPlugin. - Legacy plugin cannot be used with other Asciidoctor plugins within the same project. - Existing 1.5.x deprecated methods has been removed from legacy AsciidoctorTask. - asciidoctor#238 has been forard-ported to check that the same issue do not occur when using the compatibility task.
ysb33r
added a commit
to ysb33r/asciidoctor-gradle-plugin
that referenced
this issue
Jun 27, 2018
General: - The version series is 2.0.0. It will be kept as alpha releases for a while. - Project restructured into multiple plugins using 'base' plugin model for Asciidoctor plugins. - Only support Gradle 4.0+. - Only support JDK8+. - For Gradle 4.5+ migration messages are controlled via `--warning-mode`. - For Gradle 4.0-4.4 migration messages are controlled via `--info`. - Additional text will be displayed on Gradle Plugin Portal for during alpha & beta releases. - Compatibility testing has been added and initialy against Gradle versions 4.0.2, 4.3.1 & 4.6. (For JDK10 only test against 4.7). - Some integration tests contain JRuby compatibility tests. Current test set is 1.7.27, 9.0.5.0/9.1.0.0, 9.1.17.0, 9.2.0.0. - JDK compatibility testing are done from JDK8 -> JDK10 (Travis) - Codenarc settings has been updated to find configuration from within subprojects. - Updated license headers to include 2018. - Integration tests utilises an offline Ivy repository (via Ivypot plugin) to reduce bandwith usage and test time. - AsciidoctorJ, GroovyDSL etc. versions are defined in code and read by the build script. This provides one point of definition and ensure that code can have appropriate default versions. - Test versions of JRuby and AsciidoctorJ is controlled via test fixtures. - Renamed AsciidoctorPlugin to AsciidoctorCompatiblityPlugin - Provide ability to either use AsciidoctorJ or AsciidoctorJS as the engine. (In this commit only AsciidoctorJ is implemented). - Test result logged in real-time when running on Appveyor. New generation AsciidoctorJ plugins and tasks: - New (JVM) AsciidoctorJ extension can be added to both project & tasks. Extension in task can be used to override global settings from the project extension. It takes into account some of the ideas @manuelprinz had for asciidoctor#231 for is much more extensive. - Extension has support for Asciidoctor verbose mode (asciidoctor#233). If `verboseMode` is set then a temporary file will be created and made part of Asciidoctor `requires`. - AsciidoctorJ v1.6.0-alpha.6 is the default version, but it is possible to set a 1.5.x version if required. - JRuby version can be controlled at both project and task level. If no version is specified at either level, the maximum of default the JRuby version that AsciidoctorJ depends on and a coded minimum safe version of JRuby, will be used. - AsciidoctorJExtension maintains it's own detached configuration which can be fine turned via resolution strategies for edge cases. - the `org.asciidoctor.jvm.base` plugin adds a dependency report specifically for the detached configuration. - GroovyDSL extensions are now registered either on the project extension or the task extensions. The extensions are only loaded within a worker instance. The asciidoctor task is unloaded at the end of the worker and with it the extensions. (asciidoctor#166) - AsciidoctorTask differentitates between top-level sources, secondary sources and resources in order to have a better idea of being out-of-date. (asciidoctor#185) - It is possible to control whether resources should be copied or not. This allows a build to better deal with a backend such as PDF, which do not need resources to be copied. - It is possible to perform the conversion from an intermediate working directory, which allows for a source directory to be kept pristine from intermediate artifacts generated from extensions such as ditaa. - Using a worker approach for running Asciidoctor instances. (asciidoctor#220) - Asciidoctor tasks can be configured to run AsciidoctorJ conversions in or out of process. Even when running in process AsciidoctorJ will be on an isolated classpath. - Tasks support parallel mode which will run each backend (or in the case of Epub, each output format) in a separate worker. This behevaiour can be turned off in which case only one Asciidoctor instance is used to run all conversions in sequence. - For cases where Gradle's idea of supplementing the classpath for workers do fail, there is a special `inProcess = JAVA_EXEC` that will run the conversion out of process, albeit less efficient than an out-of-process worker. - Due to Gradle API classpath leakage, builds with Gradle 4.0-4.2 will always run in `JAVA_EXEC` mode to prevent issues. - `AsciidoctorJPdf` plugin has been added which adds a single `asciidoctorPdf` task and configures it accordingly to PDF behaviour. It also sets a default version of the `asciidoctorj-pdf` dependency. - If the PDF backend is used and the JRuby version starts with '9.x' then place SnakeYaml v1.13 on the classpath. - Backends and separateOutputDirs are configured via an outputOptions closure or action. - `AsciidoctorJEpub` plugin has been added which adds a single `asciidoctorEpub` task and configures it accordingly to EPUB behaviour. It also sets a default version of the `asciidoctorj-epub` dependency. - Epub output formats can be set via the `ebookFormats` method. - Additional Kindlegen plugin which is invoked by EPUB for when the format is KF8. The plugin will bootstrap kindlegen on all supported platforms. - Work around gradle/gradle#3698 and Xerces API clash by running EPub conversions using `inProcess = JAVA_EXEC`. Also depend on `groovy-all` dependency rather than `localGroovy()` to see if that provides relief for the issue. - Asciidoctorj-diagram supprot is in-built. Just specify the version on the extension and the artifact will be added to the classpatj. The necessary addition will be made to `requires` as well. - All methods on the new task classes that take closures as parameters now also have equivalent Action parameters (asciidoctor#236). - All new tasks are supportd by integration tests and compatibility tests. (asciidoctor#180) - Various tests use a combination of JRuby & AsciidoctorJ versions to test compatibility at the integration test level. Known issues: - Intermittent failures in tests related to bad file descriptor. Could be similar to asciidoctor/asciidoctorj#442. - EPUB3 + KF8 in one task (PendingFeature). Both formats in one task is currently failing. The exact failure message depends on which order (KF8+EPUB3 or EPUB3+KF8) the conversion takes place in. - KF8 conversions fails under Windows. Related to asciidoctor/asciidoctorj#659 & jruby/jruby#4943. - Does not work with JDK9 (but does with JDK10). Backwards compatibility and migration: - Legacy code moved to 'org.asciidoctor.gradle.compat' package, but get AsciidoctorTask in same package for compatibility purpose. - Renamed AsciidoctorPlugin to AsciidoctorCompatibilityPlugin. - Legacy plugin cannot be used with other Asciidoctor plugins within the same project. - Existing 1.5.x deprecated methods has been removed from legacy AsciidoctorTask. - asciidoctor#238 has been forard-ported to check that the same issue do not occur when using the compatibility task.
ysb33r
added a commit
to ysb33r/asciidoctor-gradle-plugin
that referenced
this issue
Jun 27, 2018
General: - The version series is 2.0.0. It will be kept as alpha releases for a while. - Project restructured into multiple plugins using 'base' plugin model for Asciidoctor plugins. - Only support Gradle 4.0+. - Only support JDK8+. - For Gradle 4.5+ migration messages are controlled via `--warning-mode`. - For Gradle 4.0-4.4 migration messages are controlled via `--info`. - Additional text will be displayed on Gradle Plugin Portal for during alpha & beta releases. - Compatibility testing has been added and initialy against Gradle versions 4.0.2, 4.3.1 & 4.6. (For JDK10 only test against 4.7). - Some integration tests contain JRuby compatibility tests. Current test set is 1.7.27, 9.0.5.0/9.1.0.0, 9.1.17.0, 9.2.0.0. - JDK compatibility testing are done from JDK8 -> JDK10 (Travis) - Codenarc settings has been updated to find configuration from within subprojects. - Updated license headers to include 2018. - Integration tests utilises an offline Ivy repository (via Ivypot plugin) to reduce bandwith usage and test time. - AsciidoctorJ, GroovyDSL etc. versions are defined in code and read by the build script. This provides one point of definition and ensure that code can have appropriate default versions. - Test versions of JRuby and AsciidoctorJ is controlled via test fixtures. - Renamed AsciidoctorPlugin to AsciidoctorCompatiblityPlugin - Provide ability to either use AsciidoctorJ or AsciidoctorJS as the engine. (In this commit only AsciidoctorJ is implemented). - Test result logged in real-time when running on Appveyor. New generation AsciidoctorJ plugins and tasks: - New (JVM) AsciidoctorJ extension can be added to both project & tasks. Extension in task can be used to override global settings from the project extension. It takes into account some of the ideas @manuelprinz had for asciidoctor#231 for is much more extensive. - Extension has support for Asciidoctor verbose mode (asciidoctor#233). If `verboseMode` is set then a temporary file will be created and made part of Asciidoctor `requires`. - AsciidoctorJ v1.6.0-alpha.6 is the default version, but it is possible to set a 1.5.x version if required. - JRuby version can be controlled at both project and task level. If no version is specified at either level, the maximum of default the JRuby version that AsciidoctorJ depends on and a coded minimum safe version of JRuby, will be used. - AsciidoctorJExtension maintains it's own detached configuration which can be fine turned via resolution strategies for edge cases. - the `org.asciidoctor.jvm.base` plugin adds a dependency report specifically for the detached configuration. - GroovyDSL extensions are now registered either on the project extension or the task extensions. The extensions are only loaded within a worker instance. The asciidoctor task is unloaded at the end of the worker and with it the extensions. (asciidoctor#166) - AsciidoctorTask differentitates between top-level sources, secondary sources and resources in order to have a better idea of being out-of-date. (asciidoctor#185) - It is possible to control whether resources should be copied or not. This allows a build to better deal with a backend such as PDF, which do not need resources to be copied. - It is possible to perform the conversion from an intermediate working directory, which allows for a source directory to be kept pristine from intermediate artifacts generated from extensions such as ditaa. - Using a worker approach for running Asciidoctor instances. (asciidoctor#220) - Asciidoctor tasks can be configured to run AsciidoctorJ conversions in or out of process. Even when running in process AsciidoctorJ will be on an isolated classpath. - Tasks support parallel mode which will run each backend (or in the case of Epub, each output format) in a separate worker. This behevaiour can be turned off in which case only one Asciidoctor instance is used to run all conversions in sequence. - For cases where Gradle's idea of supplementing the classpath for workers do fail, there is a special `inProcess = JAVA_EXEC` that will run the conversion out of process, albeit less efficient than an out-of-process worker. - Due to Gradle API classpath leakage, builds with Gradle 4.0-4.2 will always run in `JAVA_EXEC` mode to prevent issues. - `AsciidoctorJPdf` plugin has been added which adds a single `asciidoctorPdf` task and configures it accordingly to PDF behaviour. It also sets a default version of the `asciidoctorj-pdf` dependency. - If the PDF backend is used and the JRuby version starts with '9.x' then place SnakeYaml v1.13 on the classpath. - Backends and separateOutputDirs are configured via an outputOptions closure or action. - `AsciidoctorJEpub` plugin has been added which adds a single `asciidoctorEpub` task and configures it accordingly to EPUB behaviour. It also sets a default version of the `asciidoctorj-epub` dependency. - Epub output formats can be set via the `ebookFormats` method. - Additional Kindlegen plugin which is invoked by EPUB for when the format is KF8. The plugin will bootstrap kindlegen on all supported platforms. - Work around gradle/gradle#3698 and Xerces API clash by running EPub conversions using `inProcess = JAVA_EXEC`. Also depend on `groovy-all` dependency rather than `localGroovy()` to see if that provides relief for the issue. - Asciidoctorj-diagram supprot is in-built. Just specify the version on the extension and the artifact will be added to the classpatj. The necessary addition will be made to `requires` as well. - All methods on the new task classes that take closures as parameters now also have equivalent Action parameters (asciidoctor#236). - All new tasks are supportd by integration tests and compatibility tests. (asciidoctor#180) - Various tests use a combination of JRuby & AsciidoctorJ versions to test compatibility at the integration test level. Known issues: - Intermittent failures in tests related to bad file descriptor. Could be similar to asciidoctor/asciidoctorj#442. - EPUB3 + KF8 in one task (PendingFeature). Both formats in one task is currently failing. The exact failure message depends on which order (KF8+EPUB3 or EPUB3+KF8) the conversion takes place in. - KF8 conversions fails under Windows. Related to asciidoctor/asciidoctorj#659 & jruby/jruby#4943. - Does not work with JDK9 (but does with JDK10). Backwards compatibility and migration: - Legacy code moved to 'org.asciidoctor.gradle.compat' package, but get AsciidoctorTask in same package for compatibility purpose. - Renamed AsciidoctorPlugin to AsciidoctorCompatibilityPlugin. - Legacy plugin cannot be used with other Asciidoctor plugins within the same project. - Existing 1.5.x deprecated methods has been removed from legacy AsciidoctorTask. - asciidoctor#238 has been forard-ported to check that the same issue do not occur when using the compatibility task.
ysb33r
added a commit
to ysb33r/asciidoctor-gradle-plugin
that referenced
this issue
Jun 27, 2018
General: - The version series is 2.0.0. It will be kept as alpha releases for a while. - Project restructured into multiple plugins using 'base' plugin model for Asciidoctor plugins. - Only support Gradle 4.0+. - Only support JDK8+. - For Gradle 4.5+ migration messages are controlled via `--warning-mode`. - For Gradle 4.0-4.4 migration messages are controlled via `--info`. - Additional text will be displayed on Gradle Plugin Portal for during alpha & beta releases. - Compatibility testing has been added and initialy against Gradle versions 4.0.2, 4.3.1 & 4.6. (For JDK10 only test against 4.7). - Some integration tests contain JRuby compatibility tests. Current test set is 1.7.27, 9.0.5.0/9.1.0.0, 9.1.17.0, 9.2.0.0. - JDK compatibility testing are done from JDK8 -> JDK10 (Travis) - Codenarc settings has been updated to find configuration from within subprojects. - Updated license headers to include 2018. - Integration tests utilises an offline Ivy repository (via Ivypot plugin) to reduce bandwith usage and test time. - AsciidoctorJ, GroovyDSL etc. versions are defined in code and read by the build script. This provides one point of definition and ensure that code can have appropriate default versions. - Test versions of JRuby and AsciidoctorJ is controlled via test fixtures. - Renamed AsciidoctorPlugin to AsciidoctorCompatiblityPlugin - Provide ability to either use AsciidoctorJ or AsciidoctorJS as the engine. (In this commit only AsciidoctorJ is implemented). - Test result logged in real-time when running on Appveyor. New generation AsciidoctorJ plugins and tasks: - New (JVM) AsciidoctorJ extension can be added to both project & tasks. Extension in task can be used to override global settings from the project extension. It takes into account some of the ideas @manuelprinz had for asciidoctor#231 for is much more extensive. - Extension has support for Asciidoctor verbose mode (asciidoctor#233). If `verboseMode` is set then a temporary file will be created and made part of Asciidoctor `requires`. - AsciidoctorJ v1.6.0-alpha.6 is the default version, but it is possible to set a 1.5.x version if required. - JRuby version can be controlled at both project and task level. If no version is specified at either level, the maximum of default the JRuby version that AsciidoctorJ depends on and a coded minimum safe version of JRuby, will be used. - AsciidoctorJExtension maintains it's own detached configuration which can be fine turned via resolution strategies for edge cases. - the `org.asciidoctor.jvm.base` plugin adds a dependency report specifically for the detached configuration. - GroovyDSL extensions are now registered either on the project extension or the task extensions. The extensions are only loaded within a worker instance. The asciidoctor task is unloaded at the end of the worker and with it the extensions. (asciidoctor#166) - AsciidoctorTask differentitates between top-level sources, secondary sources and resources in order to have a better idea of being out-of-date. (asciidoctor#185) - It is possible to control whether resources should be copied or not. This allows a build to better deal with a backend such as PDF, which do not need resources to be copied. - It is possible to perform the conversion from an intermediate working directory, which allows for a source directory to be kept pristine from intermediate artifacts generated from extensions such as ditaa. - Using a worker approach for running Asciidoctor instances. (asciidoctor#220) - Asciidoctor tasks can be configured to run AsciidoctorJ conversions in or out of process. Even when running in process AsciidoctorJ will be on an isolated classpath. - Tasks support parallel mode which will run each backend (or in the case of Epub, each output format) in a separate worker. This behevaiour can be turned off in which case only one Asciidoctor instance is used to run all conversions in sequence. - For cases where Gradle's idea of supplementing the classpath for workers do fail, there is a special `inProcess = JAVA_EXEC` that will run the conversion out of process, albeit less efficient than an out-of-process worker. - Due to Gradle API classpath leakage, builds with Gradle 4.0-4.2 will always run in `JAVA_EXEC` mode to prevent issues. - `AsciidoctorJPdf` plugin has been added which adds a single `asciidoctorPdf` task and configures it accordingly to PDF behaviour. It also sets a default version of the `asciidoctorj-pdf` dependency. - If the PDF backend is used and the JRuby version starts with '9.x' then place SnakeYaml v1.13 on the classpath. - Backends and separateOutputDirs are configured via an outputOptions closure or action. - `AsciidoctorJEpub` plugin has been added which adds a single `asciidoctorEpub` task and configures it accordingly to EPUB behaviour. It also sets a default version of the `asciidoctorj-epub` dependency. - Epub output formats can be set via the `ebookFormats` method. - Additional Kindlegen plugin which is invoked by EPUB for when the format is KF8. The plugin will bootstrap kindlegen on all supported platforms. - Work around gradle/gradle#3698 and Xerces API clash by running EPub conversions using `inProcess = JAVA_EXEC`. Also depend on `groovy-all` dependency rather than `localGroovy()` to see if that provides relief for the issue. - Asciidoctorj-diagram supprot is in-built. Just specify the version on the extension and the artifact will be added to the classpatj. The necessary addition will be made to `requires` as well. - All methods on the new task classes that take closures as parameters now also have equivalent Action parameters (asciidoctor#236). - All new tasks are supportd by integration tests and compatibility tests. (asciidoctor#180) - Various tests use a combination of JRuby & AsciidoctorJ versions to test compatibility at the integration test level. Known issues: - Intermittent failures in tests related to bad file descriptor. Could be similar to asciidoctor/asciidoctorj#442. - EPUB3 + KF8 in one task (PendingFeature). Both formats in one task is currently failing. The exact failure message depends on which order (KF8+EPUB3 or EPUB3+KF8) the conversion takes place in. - KF8 conversions fails under Windows. Related to asciidoctor/asciidoctorj#659 & jruby/jruby#4943. - Does not work with JDK9 (but does with JDK10). Backwards compatibility and migration: - Legacy code moved to 'org.asciidoctor.gradle.compat' package, but get AsciidoctorTask in same package for compatibility purpose. - Renamed AsciidoctorPlugin to AsciidoctorCompatibilityPlugin. - Legacy plugin cannot be used with other Asciidoctor plugins within the same project. - Existing 1.5.x deprecated methods has been removed from legacy AsciidoctorTask. - asciidoctor#238 has been forard-ported to check that the same issue do not occur when using the compatibility task.
ysb33r
added a commit
to ysb33r/asciidoctor-gradle-plugin
that referenced
this issue
Jun 27, 2018
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.
|
Thanks @eriwen and @ysb33r and @mojavelinux for the conversation so far. It made it easy for me to get up and running with the However, once I got it working, I noticed that validation warnings don't show the offending file name: In a larger document base, this can make finding the source of the invalid reference a bit of a goose chase. |
cbeams
added a commit
to cbeams/bisq-docs
that referenced
this issue
Jun 29, 2018
![https://assets-cdn.github.com/images/email/message_cards/header.png","avatar_image_url":"https://assets-cdn.github.com/images/email/message_cards/avatar.png","action":{"name":"Open](https://assets-cdn.github.com/images/email/message_cards/header.png","avatar_image_url":"https://assets-cdn.github.com/images/email/message_cards/avatar.png","action":{"name":"Open){kind=link}
|
This is a feature that comes along with 1.5.7. All the messages now get fed through a logger, which have full context about the file to which the message applies. For the API in AsciidoctorJ, see asciidoctor/asciidoctorj#643 |
ysb33r
added
enhancement
1.[56].x
|
Since we have a workaround for 1.5.x which will still work with 1.5.7 of AsciidoctorJ and I've already starting addressing this in 2.0.x I'm not going to add an enhancement to the 1.5.x plugin series. |
ysb33r
added a commit
to ysb33r/asciidoctor-gradle-plugin
that referenced
this issue
Jul 17, 2018
- Proper logging using Log4J has been implemented for workers. - Logging for JavaExec goes to stdout which is then picked up via the JavaExec process. - The `asciidoctorj` extension can be configured to recognise certain messages as fatal errors via the `fatalWarnings` methods. - `missingIncludes` is a helper method that can be passed to the `setFatalWarnings` or `fatalWarnings` methods for the common use case of missing includes.
The final code is now available in PR #251 and will be available in 2.0-alpha.3. Full logging available for both Gradle worker implementations and JavaExec. |
ysb33r
added a commit
to ysb33r/asciidoctor-gradle-plugin
that referenced
this issue
Jul 17, 2018
- Proper logging using Log4J has been implemented for workers. - Logging for JavaExec goes to stdout which is then picked up via the JavaExec process. - The `asciidoctorj` extension can be configured to recognise certain messages as fatal errors via the `fatalWarnings` methods. - `missingIncludes` is a helper method that can be passed to the `setFatalWarnings` or `fatalWarnings` methods for the common use case of missing includes.
ysb33r
added a commit
to ysb33r/asciidoctor-gradle-plugin
that referenced
this issue
Jul 17, 2018
- Proper logging using Log4J has been implemented for workers. - Logging for JavaExec goes to stdout which is then picked up via the JavaExec process. - The `asciidoctorj` extension can be configured to recognise certain messages as fatal errors via the `fatalWarnings` methods. - `missingIncludes` is a helper method that can be passed to the `setFatalWarnings` or `fatalWarnings` methods for the common use case of missing includes.
|
Nice!
|
|
Did we agree on an API for changing the verbose mode (which is actually a global flag)? Is this an API that needs to be promoted to AsciidoctorJ? |
|
I was under the impression that we could remove the fix I had in alpha.1 once the new asciidoctorj API was in place. I can always re-add the verbose flag functionality. |
|
I've requested for a dedicated issue to be opened in AsciidoctorJ to discuss how to control the $VERBOSE global variable in Ruby from the API. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
As an asciidoctor Gradle user, I would like to enable verbose mode so that I am notified of broken intra-document links, among other things.
Expected behavior
Something like this should allow verbose output, perhaps:
Context
This will save my and others' time building our own anchor verification tools.
The text was updated successfully, but these errors were encountered: