Enable the search for module-info.class file in the META-INF/versions/ sub-directories of a JAR file.
#11153
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…ons/` sub-directories of a JAR file. If the project specifies a target Java release, only the directories for versions equal to lower to the target version will be scanned.
This was referenced Sep 20, 2025
gnodet
reviewed
Oct 6, 2025
| * taken as a fallback. | ||
| */ | ||
| try (JarFile jar = new JarFile(path.toFile())) { | ||
| try (JarFile jar = new JarFile(path.toFile(), false, JarFile.OPEN_READ, target)) { |
There was a problem hiding this comment.
When using JarFile(File), the default value for the verify argument is true. We're switching to false. Is that on purpose ? I don't really think we need signature verification at this point, right ?
There was a problem hiding this comment.
Yes, the JAR file is opened only for extracting the module name, either from the module-info.class or from the MANIFEST.MF file. I thought that verifying the JAR file was an overkill in that situation.
gnodet
approved these changes
Oct 6, 2025
💔 Some backports could not be created
Manual backportTo create the backport manually run: Questions ?Please refer to the Backport tool documentation |
gnodet
pushed a commit
to gnodet/maven
that referenced
this pull request
Oct 6, 2025
…ons/` sub-directories of a JAR file. (apache#11153) If the project specifies a target Java release, only the directories for versions equal to lower to the target version will be scanned. (cherry picked from commit f032cfe)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
By default,
java.util.jar.JarFiledoes not search for resources inMETA-INF/versions/sub-directories. For enabling this feature, we need to specify a version greater than Java 8 to the constructor. The core change of this pull request is this line:The rest is for answering the question: "which target Java version"? An easy approach would have been to set
targetunconditionally toRuntime.version(), i.e. the Java version on which Maven is running. This pull request rather allows configuration, with the intend to set the target version to the value of the--releasetarget option. This value can determine whether a dependency will be placed on the class-path or on the module-path. For example, if themodule-info.classentry of a JAR file exists only in theMETA-INF/versions/17/sub-directory, then the default location of that dependency will be the module-path only if the--releaseoption is equal or greater than 17.This pull request fixes the initial topic of apache/maven-compiler-plugin#966.