> -----Original Message----- > From: Thomas Broyer <t.bro...@gmail.com> > Sent: Wednesday, March 23, 2022 6:59 AM > To: Maven Users List <users@maven.apache.org> > Subject: Re: What steps will install dependent artifacts in local maven > repo > > 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.
That was my assumption, but I wanted to make sure I wasn't missing something. > 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/ > <https://urldefense.com/v3/__http://**A.ma.b**Awa.je/__;yZTKgQ!!BhdT!nSF > -GUfvXMkZKfT6UwuWtDIKHrECGPYNe7gBdCpFLjQNiWiJVVAT2vjXPtx60X_- > D6Jym9b2Pjn75cE$ >
