Various bug fixes in the handling of --patch-module

[desruisseaux]

Bug fixes in the handling of --patch-module option for tests and for multi-release projects, in particular when used in multi-module projects. The main issues fixed by this pull request are:

• For projects that are both multi-module and multi-release:
  • Fixed a compilation errors when a module exists only for a Java version higher than the base version.
  • Even when trying to compile the higher version separately, some classes of the base version were recompiled when they shouldn't (was caused by base version missing in the module path).
  • Determines the modules to patch by scanning the output directory instead of the <source> elements. It allows to take in account the outputs of generated sources (for example).
• For modular projects using package hierarchy (the Maven 3 way):
  • When module-info in test replaces the main module-info (I advise against this practice, but we nevertheless need to support that for compatibility reasons), remove the hack that consisted in temporarily deleting the module-info.class file of the main class.

Those bug fixes are resolved by a refactoring of the code that handle --patch-module. The new code uses these options more properly. The removal of the hack mentioned in the last above point became possible as a side-effect of this cleanup.

Instead of adding a new test case, this pull request modifies an existing one for doing more checks. It also enables another test which was previously disabled because of toolchain. This is also tested against a real project.

[Copilot]

Pull request overview

This pull request refactors the handling of --patch-module options to fix several bugs in multi-release and multi-module Maven projects. The changes eliminate a workaround that temporarily deleted module-info.class files during test compilation and improve module path resolution by scanning output directories instead of relying solely on source elements.

Key changes:

• Refactored module patching logic to properly track and replace source directories with compiled output directories across multiple compilation phases
• Changed dependency collections from List to Deque/Collection to support efficient prepending/removal operations needed for patch management
• Improved module directory scanning to handle modules that exist only in higher Java version directories

Reviewed changes

Copilot reviewed 15 out of 15 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
WorkaroundForPatchModule.java	Changed to LinkedHashMap/LinkedHashSet for predictable iteration order; simplified setLocationForModule logic
ToolExecutorForTest.java	Major refactoring: removed hack for deleting module-info.class; added methods to scan main output directories for modules; improved module path resolution
ToolExecutor.java	Changed dependencies from List to Deque; added methods for handling previous phase outputs and module directory resolution; refactored compile method to properly handle patch-module across versions
TestCompilerMojo.java	Simplified createExecutor to pass mainModulePath as parameter; renamed getTestModuleName to moduleNameFromPackageHierarchy
SourcesForRelease.java	Updated dependency type from List to Collection
SourceDirectory.java	Made parse method package-private; added META_INF constant
ForkedToolSources.java	Added isAbsent helper method and moduleSources factory method
DiagnosticLogger.java	Added null check for directory field before relativizing paths
CompilationTaskSources.java	Deleted entire file as no longer needed after removing the module-info compilation workaround
AbstractCompilerMojo.java	Updated method signatures to use Collection instead of List
Test files	Updated assertions and removed toolchain requirements

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.