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
