Here is the maven-compiler-plugin block:
------------
<plugin>
<artifactId>maven-compiler-plugin</artifactId>
<version>${maven.compiler.plugin.version}</version>
<executions>
<execution>
<phase>compile</phase>
</execution>
</executions>
<dependencies>
<dependency>
<groupId>org.codehaus.groovy</groupId>
<artifactId>groovy-eclipse-compiler</artifactId>
<version>3.7.0</version>
</dependency>
<dependency>
<groupId>org.codehaus.groovy</groupId>
<artifactId>groovy-eclipse-batch</artifactId>
<version>RELEASE</version>
</dependency>
</dependencies>
<configuration>
<compilerId>groovy-eclipse-compiler</compilerId>
</configuration>
</plugin>
--------------
I think in the limited circumstances I've been able to figure out, this is
essentially caused by specifying version "RELEASE", which means it will use the
latest released version. If we had specified version 3.0.8, we wouldn't have
seen this problem. What I still don't understand is why the 4.x versions are
compiled with Java 11. Our intranet repo does have a record of who the
uploader was, although I wouldn't be at all surprised if that person says he
has no idea why his name would be attached to that. I will pursue that.
> -----Original Message-----
> From: Thomas Broyer <t.bro...@gmail.com>
> Sent: Tuesday, March 22, 2022 11:56 AM
> To: Maven Users List <users@maven.apache.org>
> Subject: Re: What steps will install dependent artifacts in local maven
> repo
>
> This is totally unexpected behavior to me: an external artifact whose
> content would be different depending on which JDK downloaded it.
>
> Would you mind sharing the maven-compiler-plugin declaration with the
> ecj dependency? (to try replicating the issue and understand it)
>
> Le mar. 22 mars 2022 à 19:20, KARR, DAVID <dk0...@att.com> a écrit :
>
> > 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
> >
