wilx commented on code in PR #1093:
URL:
https://github.com/apache/maven-compiler-plugin/pull/1093#discussion_r3673879758
##########
src/main/java/org/apache/maven/plugin/compiler/TestCompilerMojo.java:
##########
@@ -342,23 +350,22 @@ protected void preparePaths(Set<File> sourceFiles) {
}
if
(testModuleDescriptor.name().equals(mainModuleDescriptor.name())) {
- if (compilerArgs == null) {
- compilerArgs = new ArrayList<>();
- }
- compilerArgs.add("--patch-module");
-
- StringBuilder patchModuleValue = new StringBuilder();
- patchModuleValue.append(testModuleDescriptor.name());
- patchModuleValue.append('=');
-
+ List<String> mainSourceRoots = new ArrayList<>();
for (String root : getProject().getCompileSourceRoots()) {
if (Files.exists(Paths.get(root))) {
- patchModuleValue.append(root).append(PS);
+ mainSourceRoots.add(root);
}
}
- compilerArgs.add(patchModuleValue.toString());
+ // Tests in the main module need the layered MR-JAR output
and the main sources as one patch.
+ List<File> outputPatches =
+ mainOutputDirectories.size() > 1 ?
mainOutputDirectories : Collections.emptyList();
+ addPatchModule(testModuleDescriptor.name(), outputPatches,
mainSourceRoots);
} else {
+ // The selected descriptor directory represents the main
module; patch in the remaining layers.
+ if (mainOutputDirectories.size() > 1) {
+ addPatchModule(mainModuleDescriptor.name(),
mainOutputDirectories, Collections.emptyList());
+ }
Review Comment:
The selected descriptor directory is included intentionally. A
`module-info.class` encountered on a patch path cannot replace the module
descriptor and is ignored by `javac`, so including that directory does not
reintroduce a different descriptor. From [JEP
261](https://openjdk.org/jeps/261): _The --patch-module option cannot be used
to replace module-info.class files. If a module-info.class file is found in a
module definition on a patch path then a warning will be issued and the file
will be ignored._
The directory order is important for the remaining classes. Patch-path
content takes precedence over both later patch-path entries and the original
module contents. The selected release directory must therefore come first,
followed by older versioned directories and the base output directory.
Otherwise, an older patched class can incorrectly shadow the corresponding
class from the selected release.
I reproduced this with a class present in both the selected Java 11 layer
and the base layer. With `--patch-module module=v11:base`, compilation
correctly sees the Java 11 class. After removing `v11` from the patch path, the
base class shadows it and compilation fails when a Java 11-only method is
referenced.
I agree that the “remaining layers” comment is misleading; I will reword it
to explain that all output layers are patched in multirelease lookup order.
--
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]
