desruisseaux commented on code in PR #3392:
URL: https://github.com/apache/maven-surefire/pull/3392#discussion_r3613415949
##########
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/booterclient/ModularClasspathForkConfiguration.java:
##########
@@ -184,6 +187,16 @@ File createArgsFile(
.append('"')
.append(NL);
+ // Check for module-info-patch.args generated by
maven-compiler-plugin 4.x
+ File patchArgs = findModuleInfoPatchArgs(patchFile);
+ if (patchArgs != null) {
+ // Merge the file's directives, except
--add-reads/--add-modules
+ // which surefire manages itself (see
appendModuleInfoPatchArgs)
+ appendModuleInfoPatchArgs(args, patchArgs, moduleName);
+ }
+
+ // Always auto-generate --add-opens for test packages (JUnit
needs reflection access).
+ // module-info-patch.maven cannot use ALL-UNNAMED in
add-opens, so surefire handles this.
Review Comment:
I suggest to disable the auto-generation of `--add-opens` by default. I
suggest that the default behaviour should be to use `module-info-patch.maven`
exactly as-is. We may provide an option for enabling auto-generation of
`--add-opens` if this is really what the user wants, but I would rather
encourage developers to declare `public` the methods invoked by JUnit. It is
not clear to me why some developers want to keep those methods private, as
`src/test/java` classes are not distributed anyway and `public` makes clear
that those methods are intended to be invoked from outside their package (from
this point of view, declaring test methods as `private` or package-private
seems misleading to me). Since `--add-opens` gives access to **all** private
methods, not only test methods, an encapsulation argument in favour of this
approach is questionable. I do not object if some developers really want to
keep test methods private and rely on `--add-opens`, but I think that it should
be _opt-in
_ rather than the default. A little bit in the spirit of _"integrity by
default"_ that Oracle is promoting.
--
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]
