Correction, it wasn't the "ecj" artifact, that was compiled with Java 11, it was "groovy-eclipse-batch". I still have to understand how this could happen, and what are reasonable mitigations we can set up to prevent this.
I found these artifacts in our intranet maven repo. The "4.x" artifacts were all compiled with Java 11. The 3.0.8 version was compiled with Java 8. > -----Original Message----- > From: KARR, DAVID <dk0...@att.com> > Sent: Tuesday, March 22, 2022 11:20 AM > To: Maven Users List <users@maven.apache.org> > Subject: RE: What steps will install dependent artifacts in local maven > repo > > *** Security Advisory: This Message Originated Outside of AT&T ***. > Reference http://cso.att.com/EmailSecurity/IDSP.html for more > information. > > Self-replying from my alter ego. 😊 > > I have verified that if I remove the "ecj" tree from my local repo, then > build one service with Java 11, with just "mvn package", then run a > build of a different service with Java 8, it will get the given error. > I can verify that the ecj artifact is now reinstalled into my local > maven repo. What's odd is that when I use "javap" to inspect the > BatchCompiler class file, it says it is version 50, not 55. > > I think I'm heading towards having each build, or at least each build > with a specific Java version, use a separate localRepository. That is > set in the settings.xml, and that path would be local to the build node, > not the build workspace (obviously, if we intended to use the same tree > for all Java 8 builds, and similarly one for all Java 11 builds). That > means coordinating with the people who maintain the build nodes. Yuck. > > > -----Original Message----- > > From: David Karr <davidmichaelk...@gmail.com> > > Sent: Tuesday, March 22, 2022 9:50 AM > > To: Maven Users List <users@maven.apache.org> > > Subject: What steps will install dependent artifacts in local maven > > repo > > > > Our org's builds have been using Java 8 for quite a while. We're > > starting to move some builds to Java 11. We're seeing some builds > > failing with the > > following: > > ------------- > > Execution default-compile of goal > > org.apache.maven.plugins:maven-compiler-plugin:3.8.0:compile failed: > > An API incompatibility was encountered while executing > > org.apache.maven.plugins:maven-compiler-plugin:3.8.0:compile: > > java.lang.UnsupportedClassVersionError: > > org/eclipse/jdt/core/compiler/batch/BatchCompiler has been compiled by > > a more recent version of the Java Runtime (class file version 55.0), > > this version of the Java Runtime only recognizes class file versions > > up to > > 52.0 > > ------------- > > > > This indicates that the artifact with the BatchCompiler class (ecj) > > was compiled with Java 11, but the current JVM is Java 8. > > > > I'm trying to understand the possible scenarios that could produce > > this, so we can mitigate it properly. > > > > This artifact is specified as a direct dependency of the "maven- > > compiler-plugin". It would help to understand exactly which Maven > > goals will install plugin dependencies into the local maven repo. At > > least our builds only do "mvn package" or "mvn deploy", depending on > > what is being built. > > > > However, our builds are run on a pool of Jenkins build nodes, and I'm > > not certain whether those build nodes are shared with other projects > > in our large enterprise. I'm trying to determine that. > > > > We may determine that because of these issues, we will have to specify > > a fresh empty local repository for every build, which will obviously > > make our builds take longer. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org
