slachiewicz opened a new issue, #105: URL: https://github.com/apache/maven-jdeps-plugin/issues/105
#50 (MJDEPS-15) reported this exact failure in 2019 and was closed `NOT_PLANNED` after the reporter found that upgrading from an early JDK 11 build to JDK 11.0.5 (2019-10-15) made the error disappear, implying a later `jdeps` point release started tolerating a mixed multi-release/non-multi-release classpath without the `--multi-release` flag. That does not hold on modern JDKs. Reproduced on **JDK 17.0.20 (Azul Zulu)** in apache/maven-jdeps-plugin#102 (a Dependabot bump of `plexus-utils` 3.0.24 → 3.6.1 in `src/it/dependenciesToAnalyze`), with the exact same error text as the original 2019 report: ``` Error: plexus-utils-3.6.1.jar is a multi-release jar file but --multi-release option is not set ``` This happens because `AbstractJDepsMojo`'s `multiRelease` parameter ([AbstractJDepsMojo.java:79-84](https://github.com/apache/maven-jdeps-plugin/blob/master/src/main/java/org/apache/maven/plugins/jdeps/AbstractJDepsMojo.java#L79-L84)) is passed as a single `--multi-release` flag ([line 311-313](https://github.com/apache/maven-jdeps-plugin/blob/master/src/main/java/org/apache/maven/plugins/jdeps/AbstractJDepsMojo.java#L311-L313)) covering one `jdeps` invocation for the *entire* classpath. `jdeps` itself refuses a genuinely mixed classpath either way — flag unset + a multi-release jar present errors one way, flag set + a non-multi-release jar present errors the other way — which matches JDK-8207162, cited in #50's own comments as the reason a real fix needs jdeps invoked once per multi-release-vs-not jar group with results merged, not a single plugin-wide flag. Reopening this as a new issue rather than reopening #50 since its original "upgrade your JDK" resolution is what's now disproven — this needs the actual per-classpath-group invocation fix described there and in the linked JDK bug, not another JDK-version workaround. *This change was created with AI assistance.* -- 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]
