GENTOO_VM=openjdk-17 CLASSPATH="" JAVA_HOME="/usr/lib64/openjdk-17" JAVACFLAGS="-source 1.8 -target 1.8" COMPILER="" $ emerge -pqv '=dev-java/maven-bin-3.9.0::gentoo' [ebuild NS ] dev-java/maven-bin-3.9.0 [3.8.7] CVV: 1.8 Checked: 109 Good: 107 Bad: 2 Skipped: 0 * Incorrect bytecode version found * in file: /var/tmp/portage/dev-java/maven-bin-3.9.0/image//usr/share/maven-bin-3.9/lib/plexus-utils-3.4.2.jar * See /var/tmp/portage/dev-java/maven-bin-3.9.0/temp/class-version-verify.log for more details. * ERROR: dev-java/maven-bin-3.9.0::gentoo failed (install phase): * Incorrect bytecode found
Created attachment 857251 [details] emerge --info
i guess this is not an issue of the package but instead the tool that checks the bytecode versions of the files. the mentioned jar contains multiple versions of some files and the tool does not support it. it would have to be updated to handle the versioned dirs inside the jar appropriately.
Confirmed. Temporarilly commenting out JAVA_PKG_STRICT in /etc/portage/make.conf solves it for me. /etc/portage/make.conf # JAVA_PKG_STRICT=true
yes, it's called from that function in that eclass but the fix/enhancement has to be done in javatoolkit in /usr/libexec/javatoolkit/class-version-verify.py which performs the check. a python fluent speaker could: - exclude content of META-INF/versions/ from the regular check - add extra bytecode check only for files in META-INF/versions/\d+ (if those dirs exist) that the bytecode of the files matches the version specified by \d+.
in fact the exact file is cvv.py which contains the logic.
