Inline. > -----Original Message----- > From: Alexander Kriegisch <alexan...@kriegisch.name> > Sent: Wednesday, March 23, 2022 1:11 AM > To: users@maven.apache.org > Subject: Re: What steps will install dependent artifacts in local maven > repo > > Some background information, because I happen to know, being an AspectJ > committer and the AspectJ compiler being a fork of ECJ, just like > GrEclipse is, too: > > The JDT Core project has decided a while ago - I think for the Eclipse > 4.22 (2021-12) release, maybe one release earlier - to drop Java 8 > build-time support and move on to Java 11+, because other parts of > Eclipse are based on Java 11 too and it was getting more and more > difficult to keep those libraries out with their Java 11 class files. So > now, JDT Core and therefore also recent versions of compilers like ECJ, > GrEclipse and AspectJ *had* to migrate to Java 11 as well, because they > all depend on JDT Core. > > Attention, please do not misunderstand: ECJ and e.g. AspectJ can still > compile to Java 8 target. I do not know about GrEclipse, but would > expect the same. For pure POJOs (no AspectJ or Groovy), those compilers > can even create class files for as low as Java 1.3! Javac cannot do > that, so you are more flexible than with Javac. The limitation only > applies to build time, i.e. you have to run your builds on JVM 11+, even > if you compile to target 8. > > Your error messages therefore come from builds using more recent Eclipse > (fork) compiler version, but running on JRE 8. Simply upgrade the build > environment on your workstation or Jenkins server to run on JDK 11+, > then you should be fine.
We are in the process of migrating from Java 8 to Java 11, but it is not going to be immediate. We can't simply flip a switch. I determined that groovy-eclipse-batch v3.0.8-01 is the last version that was compiled by Java 8. I need to know it will stay this way. I also am now specifying groovy-eclipse-compiler v3.7.1. I also hope that will stay on Java 8. Are both of those true? > David Karr schrieb am 22.03.2022 23:50 (GMT +07:00): > > > 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 --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
