arturobernalg opened a new pull request, #1412: URL: https://github.com/apache/maven-javadoc-plugin/pull/1412
getExcludedPackages(Collection<Path>) only computed the -exclude argument when both sourcepath and subpackages were configured. For the common case of excludePackageNames alone, with neither of those set, the method always returned an empty string, so -exclude was never passed to javadoc. On a module (module-info.java present), exclusion then relied entirely on leaving the package out of the explicit package list that addCommandLinePackages writes -- the module itself still exports it, there is just no javadoc argument asking it to be skipped. That omission trick happened to work on the javadoc tool shipped with older JDKs, but not on JDK 25/26, where the tool processes every package the module exports regardless of the package list, with or without -exclude. -exclude is always computed now whenever excludePackageNames resolves to a non-empty set, independent of subpackages/sourcepath. This is a no-op for the javadoc-tool regression itself (confirmed empirically: passing -exclude explicitly against the same module-path/patch-module invocation still does not exclude the package on JDK 26), but it closes a real, independent gap: the plugin should emit the documented exclusion argument whenever there is something to exclude, and doing so is what already makes exclusion work correctly on JDK <= 24 for a module project that only sets excludePackageNames (previously undertested: every existing subpackages/excludePackageNames IT and unit fixture also sets sourcepath or subpackages, so this path had no coverage). Added GITHUB-1271_exclude-package-module-info, a modulegetExcludedPackages(Collection<Path>) only computed the -exclude argument when both sourcepath and subpackages were configured. For the common case of excludePackageNames alone, with neither of those set, it always returned an empty string, so -exclude was never passed to javadoc. On a module (module-info.java present), exclusion then relied entirely on leaving the package out of the explicit package list that addCommandLinePackages writes -- the module itself still exports it, there's just no javadoc argument asking it to be skipped. That omission trick happened to work with the javadoc tool shipped in older JDKs, but not on JDK 25/26: there it processes every package the module exports regardless of the package list, with or without -exclude. This fix makes -exclude always be computed whenever excludePackageNames resolves to a non-empty set, independent of subpackages/sourcepath. I want to be upfront that I verified this is not a full fix for the JDK 25/26 symptom itself: I confirmed empirically (diffing the actual @options/@packages argfiles and testing -exclude explicitly against the same --module-path/--patch-module invocation) that javadoc on JDK 26 still documents the excluded package even with -exclude passed. That part looks like a javadoc-tool regression, not something fixable through plugin arguments -- I looked at physically trimming the staged source tree instead, but that's unsafe in general since javadoc still type-checks the kept files, so a non-excluded class referencing a type from the excluded package would turn into a compile error. What this does fix is a real, independent gap: the plugin should emit the documented exclusion argument whenever there's something to exclude, and doing so is exactly what already makes exclusion work correctly on JDK <= 24 for a module project that only sets excludePackageNames. That path had no test coverage at all -- every existing subpackages/excludePackageNames IT and unit fixture also sets sourcepath or subpackages, which takes a different, unaffected code path. Added GITHUB-1271_exclude-package-module-info, a module-info-based IT with no subpackages/sourcepath, asserting the generated javadoc options file contains -exclude for the configured package. Confirmed it fails on unfixed code (no -exclude in the options file at all) and passes with the fix. Full JavadocReportTest suite (31/31), the existing module-path/exclude-related ITs (MJAVADOC-449/498/506 family), checkstyle and spotless all still pass. Related to #1271. Doesn't fully close it for JDK 25/26 modular builds -- I'll follow up there once I understand whether that needs a javadoc-tool bug report or there's another angle on the plugin side. To make clear that you license your contribution under the Apache License Version 2.0, January 2004, check one of the following: - [x] I hereby declare this contribution to be licensed under the [Apache License Version 2.0, January 2004](https://www.apache.org/licenses/LICENSE-2.0) - [ ] - [x] I hereby declare that I have filed an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf).-info-based IT with no subpackages/sourcepath, asserting the generated javadoc options file contains -exclude for the configured package. Confirmed it fails on unfixed code (no -exclude in the options file) and passes with the fix. Full JavadocReportTest suite (31/31), the existing module-path and exclude-related ITs (MJAVADOC-449/498/506 family), checkstyle and spotless all still pass. <!-- Add your description here... what, why and how you resolve the issue --> --- To make clear that you license your contribution under the [Apache License Version 2.0, January 2004](https://www.apache.org/licenses/LICENSE-2.0) check one of the following: - [ ] I hereby declare this contribution to be licensed under the [Apache License Version 2.0, January 2004](https://www.apache.org/licenses/LICENSE-2.0) - [ ] I hereby declare that I have filed an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). -- 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]
