Releases are "immutable" in a Maven repository (or at least are expected to be, and the Central Repository enforces it), so if 3.7.1 is compatible with JDK 8, it will stay that way.
On Wed, Mar 23, 2022 at 2:40 PM KARR, DAVID <dk0...@att.com> wrote: > 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 > > -- Thomas Broyer /tɔ.ma.bʁwa.je/ <http://xn--nna.ma.xn--bwa-xxb.je/>
