matrei opened a new pull request, #16371: URL: https://github.com/apache/grails-core/pull/16371
`./gradlew build` fails on `:grails-gsp-spring-boot:javadocJar` on any checkout that still carries a `build/docs/javadoc/` from an earlier build: ``` Cannot copy file '.../grails-gsp/spring-boot/build/docs/groovydoc/help-doc.html' to 'help-doc.html' because file '.../grails-gsp/spring-boot/build/docs/javadoc/help-doc.html' has already been copied there. ``` ### Cause The javadoc jar of every published module has two sources. `CompilePlugin` calls `withJavadocJar()`, which adds `from(javadoc)`. The grails-publish plugin then disables the `javadoc` task on every module that has a `groovydoc` task and adds the groovydoc directory to the same jar in its place. That works on a clean checkout because a disabled `javadoc` produces nothing, but a disabled task never cleans its outputs either, so whatever an earlier build left in `build/docs/javadoc/` is packaged next to the groovydoc, and the two `help-doc.html` trip the jar's `DuplicatesStrategy.FAIL`. `grails-gsp-spring-boot` is where this shows up in practice: it only started applying the publish conventions in 14da8e4b11 (June 2026), and it is Java-only, so any build of an older checkout of this directory (`7.0.x`, or an `8.0.x` from before that commit) ran its `javadoc` and left the directory behind. Nothing on the framework side is different in this module; a `clean` or a fresh clone hides the problem, which is why CI never sees it. ### Fix `CompilePlugin` now excludes the `javadoc` task's destination directory from `javadocJar` whenever that task is disabled. Both the flag and the directory are read when the jar runs, since grails-publish disables the task lazily after the plugin has configured it. A `javadoc` that does not run has nothing to contribute, so the exclusion applies whether or not the directory exists, and an enabled `javadoc` is packaged exactly as before. ### Tests Two TestKit cases in `CompilePluginSpec`: - a disabled `javadoc` with a planted stale `build/docs/javadoc/` and a second source carrying the same `help-doc.html` builds the jar and packages only the second source — this reproduces the original failure verbatim against the unfixed plugin - an enabled `javadoc` still lands in the jar Verified locally with the stale directory still on disk: `:grails-gsp-spring-boot:javadocJar --rerun-tasks` now succeeds and the jar's entries are exactly the groovydoc output plus the manifest; `javadocJar` across every module of the root build passes; the `build-logic` build passes with all 138 plugin specs. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
