asciidoctor-gradle-plugin
asciidoctor-gradle-plugin copied to clipboard
Gradle 7.1: Deprecation warning
Running the plugin with Gradle 7.1 generates the following warning:
The JavaExecHandleBuilder.setMain(String) method has been deprecated. This is scheduled to be removed in Gradle 8.0. Please use the mainClass property instead. Consult the upgrading guide for further information: https://docs.gradle.org/7.1/userguide/upgrading_version_7.html#java_exec_properties
The link explains:
The main getters and setters in JavaExec task have been deprecated. Use the mainClass property instead.
If I upgrade the InfoQ Mini-Book template to Gradle 7.1, it fails with the following errors:
FAILURE: Build failed with an exception.
* What went wrong:
Some problems were found with the configuration of task ':html' (type 'AsciidoctorTask').
- In plugin 'org.asciidoctor.convert' type 'org.asciidoctor.gradle.AsciidoctorTask' method 'asGemPath()' should not be annotated with: @Optional, @InputDirectory.
Reason: Input/Output annotations are ignored if they are placed on something else than a getter.
Possible solutions:
1. Remove the annotations.
2. Rename the method.
Please refer to https://docs.gradle.org/7.1/userguide/validation_problems.html#ignored_annotations_on_method for more details about this problem.
- In plugin 'org.asciidoctor.convert' type 'org.asciidoctor.gradle.AsciidoctorTask' property 'logDocuments' has redundant getters: 'getLogDocuments()' and 'isLogDocuments()'.
Reason: Boolean property 'logDocuments' has both an `is` and a `get` getter.
Possible solutions:
1. Remove one of the getters.
2. Annotate one of the getters with @Internal.
Please refer to https://docs.gradle.org/7.1/userguide/validation_problems.html#redundant_getters for more details about this problem.
- In plugin 'org.asciidoctor.convert' type 'org.asciidoctor.gradle.AsciidoctorTask' property 'separateOutputDirs' has redundant getters: 'getSeparateOutputDirs()' and 'isSeparateOutputDirs()'.
Reason: Boolean property 'separateOutputDirs' has both an `is` and a `get` getter.
Possible solutions:
1. Remove one of the getters.
2. Annotate one of the getters with @Internal.
Please refer to https://docs.gradle.org/7.1/userguide/validation_problems.html#redundant_getters for more details about this problem.
* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights.
* Get more help at https://help.gradle.org
BUILD FAILED in 14s
> Task :html FAILED
Is it possible to fix this?
If I downgrade to Gradle 6.9, everything works.
./gradlew wrapper --gradle-version 6.9 --distribution-type bin
It looks like the main class is configured in the Gradle task here: https://github.com/asciidoctor/asciidoctor-gradle-plugin/blob/34837b18609821bd85c239453a3111d13c1e0d0a/jvm/src/main/groovy/org/asciidoctor/gradle/jvm/AbstractAsciidoctorTask.groovy#L582
@mraible Please don't mix threads. Your issue is completely different from what this ticket has been opened for. First of all you are using some archaic Asciidoctor Gradle Plugin version. I can see that you use org.asciidoctor:asciidoctor-gradle-plugin:1.6.1
from April 2019. There is no way that it will work with Gradle 7.x (at that time Gradle was at 5.x). Please consider migrating to org.asciidoctor:asciidoctor-gradle-jvm:3.3.2
. If you have more questions please open a new ticket.
@hiddewie I think I'll find some time later today to post a merge request with a fix.
Duplicate of #602
I'm interested in this as I'm using this plugin with Gradle 7.2.
Having a look at the Gradle docs the mainClass
property has been added starting version 6.8.
I would be happy to try contributing but would need some guidance as I never worked on a Gradle plugin yet...
Just change the property in the line mentioned by @hiddewie would make the plugin incompatible for users having Gradle < 6.8.
Is there a way to make the code smart enough to choose mainClass
if it exists and fall back to main
if not?
Should do the change, increase the major to indicate this breaking change?
@jannis-baratheon Thanks for the link!
Are you able to point to a migration guide? Or do you have any advice regarding such migration? I have struggled to find the appropriate documentation and seem to be utterly lost!
@AlexandreCassagne I was upgrading from 1.x to 3.x , but it was more than a year ago so I remember it only vaguely. But it wasn't trivial - the API have changed from 1.x. I have not found a migration guide anywhere. The upgrade was hard and close to a rewrite rather than a smooth transition. If you have concrete questions I might try and answer them.
Please try 4.0.0-alpha.1 and tell me if the problem still exists