https://issues.apache.org/jira/browse/GROOVY-11671 is the ticket for the 4_0_X branch failing.
On Sun, May 18, 2025 at 6:40 AM Paul King <pa...@asert.com.au> wrote: > I think our standard checks run *checkstyleMain *not > *checkstyleMainReport*. Do you want to raise a Jira please? > > It's to do with the fact that groovy-cli-picocli contains no Java source > files, just Groovy, so there is nothing to "check". The @SkipWhenEmpty > annotation on the task skips checking in that case but maybe the > bad-practices-detection hasn't been updated to also skip and is flagging a > false positive. > > Paul. > > > On Sun, May 18, 2025 at 3:07 PM James Daugherty < > jdaughe...@jdresources.net> wrote: > >> I implemented this here: >> https://github.com/jdaugherty/groovy/tree/GROOVY-11668 but I seem to be >> having a problem building the groovy project. >> >> I switched to 4_0_X (the base branch of my branch), and attempted to >> build, and it's failing too. >> >> Is anyone familiar with the below error? It appears a file is missing >> that's expected: >> >> * What went wrong: >> A problem was found with the configuration of task >> ':groovy-cli-picocli:checkstyleMainReport' (type 'CheckstyleHtmlReport'). >> - In plugin 'org.apache.groovy-bad-practices-detection' type >> 'org.apache.groovy.gradle.CheckstyleHtmlReport' property >> 'checkstyleReportFile' specifies file >> 'myprojectdirectory/subprojects/groovy-cli-picocli/build/reports/checkstyle/checkstyleMain.xml' >> which doesn't exist. >> >> Reason: An input file was expected to be present but it doesn't exist. >> >> Possible solutions: >> 1. Make sure the file exists before the task is called. >> 2. Make sure that the task which produces the file is declared as >> an input. >> >> For more information, please refer to >> https://docs.gradle.org/8.14/userguide/validation_problems.html#input_file_does_not_exist >> in the Gradle documentation. >> >> * Try: >> > Make sure the file exists before the task is called >> > Make sure that the task which produces the file is declared as an input >> >> >> On Sat, May 17, 2025 at 11:02 PM James Daugherty < >> jdaughe...@jdresources.net> wrote: >> >>> I opened https://issues.apache.org/jira/browse/GROOVY-11668 and will >>> take a look at submitting a pull request. Thank you. >>> >>> On Sat, May 17, 2025 at 8:04 PM Paul King <pa...@asert.com.au> wrote: >>> >>>> A pull request would be great! >>>> >>>> Paul. >>>> >>>> >>>> On Sun, May 18, 2025 at 2:33 AM James Daugherty < >>>> jdaughe...@jdresources.net> wrote: >>>> >>>>> Hi Everyone, >>>>> >>>>> I am trying to modernize the Apache Grails code base since we're using >>>>> Groovy 4.0.26 & Java 17 as a baseline. In our gradle project, we have the >>>>> language level set to Java 17. We also have java files in our groovy >>>>> source sets. After updating our java files to use more modern features, >>>>> I'm getting a failure when running groovydoc. An example of this is: >>>>> >>>>> > Task :grails-core:groovydoc >>>>> Attempting to ignore error parsing Java source file: >>>>> org/grails/plugins/DefaultGrailsPlugin.java >>>>> Consider reporting the error to the Groovy project: >>>>> https://issues.apache.org/jira/browse/GROOVY >>>>> ... or directly to the JavaParser project: >>>>> https://github.com/javaparser/javaparser/issues >>>>> Error: (line 181,col 13) Use of patterns with instanceof is not >>>>> supported. Pay attention that this feature is supported starting from >>>>> 'JAVA_14' language level. If you need that feature the language level must >>>>> be configured in the configuration before parsing the source files. >>>>> >>>>> The cause for this error is groovydoc uses the JavaParser library and >>>>> its default language level is set to a lower value (it currently defaults >>>>> to the popular language level which is Java 11). If I was using this >>>>> library directly, I would set this option to force a specific java >>>>> version: >>>>> >>>>> >>>>> StaticJavaParser.getConfiguration().setLanguageLevel(ParserConfiguration.LanguageLevel.JAVA_17) >>>>> >>>>> I searched >>>>> https://github.com/apache/groovy/blob/master/subprojects/groovy-groovydoc >>>>> and I don't see a level being set. I also don't see any mention of this >>>>> in >>>>> jira. Finally, I don't see any documented parameters where this can be >>>>> set: https://groovy-lang.org/groovydoc.html >>>>> >>>>> Is anyone aware of how to set this language level for the existing >>>>> groovydoc task? Would an argument to groovydoc be the preferred way to >>>>> set >>>>> this language level? If such a flag were added, I could request a gradle >>>>> upstream change to set this flag based on the project language level. Has >>>>> this issue been raised before? >>>>> >>>>> I'm happy to submit a pull request to make this change, but thought >>>>> I'd check here first on how best to add this support or if I've missed >>>>> some >>>>> other way to set the language level. >>>>> >>>>> -James >>>>> >>>>
