Development 2.0 #237
Merged
Development 2.0 #237
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
ysb33r
force-pushed
the
development-1.6
branch
3 times, most recently
from
f2b70fc
to
8f66509
Compare
Closed
ysb33r
force-pushed
the
development-1.6
branch
6 times, most recently
from
dc38634
to
7979e29
Compare
ysb33r
force-pushed
the
development-1.6
branch
20 times, most recently
from
5266a88
to
1d4ce4e
Compare
ysb33r
force-pushed
the
development-1.6
branch
11 times, most recently
from
99a7cb4
to
37becba
Compare
|
@aalmiray @mojavelinux I think this is ready to be merged into the repo on the development-1.6 branch. Once it is merged, we can create a new branch development-2.0 and delete the devlopment-1.6 branch. The basic functioanlity now works of the 3 major operating systems and JDK8, 10. There are quite a number fo functionality tests I still need to implement, but they can be done over the next few weeks. I think it is more important to get an early Alpha release out for people to play with and get the feedback coming in. |
ysb33r
force-pushed
the
development-1.6
branch
6 times, most recently
from
fad0a73
to
ce9cda5
Compare
ysb33r
force-pushed
the
development-1.6
branch
6 times, most recently
from
24f07cf
to
6f89f39
Compare
General: - The version series is 2.0.0. It will be kept as alpha releases for a while. - Project restructured into multiple plugins using 'base' plugin model for Asciidoctor plugins. - Only support Gradle 4.0+. - Only support JDK8+. - For Gradle 4.5+ migration messages are controlled via `--warning-mode`. - For Gradle 4.0-4.4 migration messages are controlled via `--info`. - Additional text will be displayed on Gradle Plugin Portal for during alpha & beta releases. - Compatibility testing has been added and initialy against Gradle versions 4.0.2, 4.3.1 & 4.6. (For JDK10 only test against 4.7). - Some integration tests contain JRuby compatibility tests. Current test set is 1.7.27, 9.0.5.0/9.1.0.0, 9.1.17.0, 9.2.0.0. - JDK compatibility testing are done from JDK8 -> JDK10 (Travis) - Codenarc settings has been updated to find configuration from within subprojects. - Updated license headers to include 2018. - Integration tests utilises an offline Ivy repository (via Ivypot plugin) to reduce bandwith usage and test time. - AsciidoctorJ, GroovyDSL etc. versions are defined in code and read by the build script. This provides one point of definition and ensure that code can have appropriate default versions. - Test versions of JRuby and AsciidoctorJ is controlled via test fixtures. - Renamed AsciidoctorPlugin to AsciidoctorCompatiblityPlugin - Provide ability to either use AsciidoctorJ or AsciidoctorJS as the engine. (In this commit only AsciidoctorJ is implemented). - Test result logged in real-time when running on Appveyor. New generation AsciidoctorJ plugins and tasks: - New (JVM) AsciidoctorJ extension can be added to both project & tasks. Extension in task can be used to override global settings from the project extension. It takes into account some of the ideas @manuelprinz had for asciidoctor#231 for is much more extensive. - Extension has support for Asciidoctor verbose mode (asciidoctor#233). If `verboseMode` is set then a temporary file will be created and made part of Asciidoctor `requires`. - AsciidoctorJ v1.6.0-alpha.6 is the default version, but it is possible to set a 1.5.x version if required. - JRuby version can be controlled at both project and task level. If no version is specified at either level, the maximum of default the JRuby version that AsciidoctorJ depends on and a coded minimum safe version of JRuby, will be used. - AsciidoctorJExtension maintains it's own detached configuration which can be fine turned via resolution strategies for edge cases. - the `org.asciidoctor.jvm.base` plugin adds a dependency report specifically for the detached configuration. - GroovyDSL extensions are now registered either on the project extension or the task extensions. The extensions are only loaded within a worker instance. The asciidoctor task is unloaded at the end of the worker and with it the extensions. (asciidoctor#166) - AsciidoctorTask differentitates between top-level sources, secondary sources and resources in order to have a better idea of being out-of-date. (asciidoctor#185) - It is possible to control whether resources should be copied or not. This allows a build to better deal with a backend such as PDF, which do not need resources to be copied. - It is possible to perform the conversion from an intermediate working directory, which allows for a source directory to be kept pristine from intermediate artifacts generated from extensions such as ditaa. - Using a worker approach for running Asciidoctor instances. (asciidoctor#220) - Asciidoctor tasks can be configured to run AsciidoctorJ conversions in or out of process. Even when running in process AsciidoctorJ will be on an isolated classpath. - Tasks support parallel mode which will run each backend (or in the case of Epub, each output format) in a separate worker. This behevaiour can be turned off in which case only one Asciidoctor instance is used to run all conversions in sequence. - For cases where Gradle's idea of supplementing the classpath for workers do fail, there is a special `inProcess = JAVA_EXEC` that will run the conversion out of process, albeit less efficient than an out-of-process worker. - Due to Gradle API classpath leakage, builds with Gradle 4.0-4.2 will always run in `JAVA_EXEC` mode to prevent issues. - `AsciidoctorJPdf` plugin has been added which adds a single `asciidoctorPdf` task and configures it accordingly to PDF behaviour. It also sets a default version of the `asciidoctorj-pdf` dependency. - If the PDF backend is used and the JRuby version starts with '9.x' then place SnakeYaml v1.13 on the classpath. - Backends and separateOutputDirs are configured via an outputOptions closure or action. - `AsciidoctorJEpub` plugin has been added which adds a single `asciidoctorEpub` task and configures it accordingly to EPUB behaviour. It also sets a default version of the `asciidoctorj-epub` dependency. - Epub output formats can be set via the `ebookFormats` method. - Additional Kindlegen plugin which is invoked by EPUB for when the format is KF8. The plugin will bootstrap kindlegen on all supported platforms. - Work around gradle/gradle#3698 and Xerces API clash by running EPub conversions using `inProcess = JAVA_EXEC`. Also depend on `groovy-all` dependency rather than `localGroovy()` to see if that provides relief for the issue. - Asciidoctorj-diagram supprot is in-built. Just specify the version on the extension and the artifact will be added to the classpatj. The necessary addition will be made to `requires` as well. - All methods on the new task classes that take closures as parameters now also have equivalent Action parameters (asciidoctor#236). - All new tasks are supportd by integration tests and compatibility tests. (asciidoctor#180) - Various tests use a combination of JRuby & AsciidoctorJ versions to test compatibility at the integration test level. Known issues: - Intermittent failures in tests related to bad file descriptor. Could be similar to asciidoctor/asciidoctorj#442. - EPUB3 + KF8 in one task (PendingFeature). Both formats in one task is currently failing. The exact failure message depends on which order (KF8+EPUB3 or EPUB3+KF8) the conversion takes place in. - KF8 conversions fails under Windows. Related to asciidoctor/asciidoctorj#659 & jruby/jruby#4943. - Does not work with JDK9 (but does with JDK10). Backwards compatibility and migration: - Legacy code moved to 'org.asciidoctor.gradle.compat' package, but get AsciidoctorTask in same package for compatibility purpose. - Renamed AsciidoctorPlugin to AsciidoctorCompatibilityPlugin. - Legacy plugin cannot be used with other Asciidoctor plugins within the same project. - Existing 1.5.x deprecated methods has been removed from legacy AsciidoctorTask. - asciidoctor#238 has been forard-ported to check that the same issue do not occur when using the compatibility task.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is experimental work on a new generation of Asciidoctor Gradle plugins.
It is currently here on a PR for visibility and experimentation.