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 >>>> >>>
