jdaugherty opened a new pull request, #37: URL: https://github.com/apache/grails-gradle-publish/pull/37
Fixes #36. Also closes #23, since after this the javadoc jar is groovydoc-only in practice as well as in intent. ### Cause `validateProjectPublishable` calls `withJavadocJar()`, which registers `javadocJar` with `from(javadoc)`. The plugin then disables `javadoc` on every project that has a `groovydoc` task and adds the groovydoc directory to the same jar. Keeping the standard tasks in place is deliberate — it is what lets the rest of Gradle depend on them — and only the jar's *content* is meant to be swapped for the groovydoc. But the `from(javadoc)` was never taken away, and a disabled task never cleans its outputs. So whatever an earlier build left in `build/docs/javadoc` is still packaged next to the groovydoc. On a clean tree that directory is empty and it goes unnoticed. With content in it, the jar either silently ships stale pages (a `p/A.html` for a class that no longer exists goes in without a word) or fails outright for consumers that set `DuplicatesStrategy.FAIL`, on the two `help-doc.html`. Content gets there easily — any build of the same checkout from before the plugin was applied to that module, since a plain `withJavadocJar()` runs `javadoc` into exactly that directory. CI never sees it because it always starts clean, so it only bites developers, and the failure points nowhere near the cause. ### Fix A `javadoc` task that does not run has nothing to contribute, so its destination directory is now excluded from `javadocJar` whenever the task is disabled. Both the flag and the directory are read lazily, since the task is disabled after the jar has been configured. The exclusion applies whether or not the directory exists; an enabled `javadoc` is packaged exactly as before. apache/grails-core#16371 works around this in the framework's own convention plugin — it can be reverted once this ships, and every other consumer is covered without having to discover the problem first. ### Tests New fixture `other-artifacts/stale-javadoc-output` (a Groovy project with `DuplicatesStrategy.FAIL` on its jars, as grails-core sets) plus a spec case that plants a stale `build/docs/javadoc/` holding a colliding `help-doc.html` and a `removed/DeletedClass.html` for a class that no longer exists. Against the unfixed plugin it reproduces the reported failure verbatim: ``` Cannot copy file '.../build/docs/groovydoc/help-doc.html' to 'help-doc.html' because file '.../build/docs/javadoc/help-doc.html' has already been copied there. ``` The enabled-javadoc path is already covered by the existing "java only project" case. Verified locally: full `:grails-publish:check` green (53 tests, 0 failures; the 6 skipped are the pre-existing `@PendingFeature` cases), `rat` passes, and a hand run of the fixture with `--configuration-cache` stores and reuses its entry cleanly, producing a jar whose entries are exactly the groovydoc output plus the manifest. 🤖 Generated with [Claude Code](https://claude.com/claude-code) -- 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]
