You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by David Karr <da...@gmail.com> on 2022/03/22 16:50:13 UTC
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.
RE: What steps will install dependent artifacts in local maven repo
Posted by "KARR, DAVID" <dk...@att.com>.
> -----Original Message-----
> From: Thomas Broyer <t....@gmail.com>
> Sent: Wednesday, March 23, 2022 6:59 AM
> To: Maven Users List <us...@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 <dk...@att.com> wrote:
>
> > Inline.
> >
> > > -----Original Message-----
> > > From: Alexander Kriegisch <al...@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-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@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$ >
Re: What steps will install dependent artifacts in local maven repo
Posted by Thomas Broyer <t....@gmail.com>.
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 <dk...@att.com> wrote:
> Inline.
>
> > -----Original Message-----
> > From: Alexander Kriegisch <al...@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-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
--
Thomas Broyer
/tɔ.ma.bʁwa.je/ <http://xn--nna.ma.xn--bwa-xxb.je/>
RE: What steps will install dependent artifacts in local maven repo
Posted by "KARR, DAVID" <dk...@att.com>.
Inline.
> -----Original Message-----
> From: Alexander Kriegisch <al...@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-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: What steps will install dependent artifacts in local maven repo
Posted by Alexander Kriegisch <al...@kriegisch.name>.
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.
--
Alexander Kriegisch
https://scrum-master.de
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-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: What steps will install dependent artifacts in local maven repo
Posted by "KARR, DAVID" <dk...@att.com>.
Correction, it wasn't the "ecj" artifact, that was compiled with Java 11, it was "groovy-eclipse-batch". I still have to understand how this could happen, and what are reasonable mitigations we can set up to prevent this.
I found these artifacts in our intranet maven repo. The "4.x" artifacts were all compiled with Java 11. The 3.0.8 version was compiled with Java 8.
> -----Original Message-----
> From: KARR, DAVID <dk...@att.com>
> Sent: Tuesday, March 22, 2022 11:20 AM
> To: Maven Users List <us...@maven.apache.org>
> Subject: RE: What steps will install dependent artifacts in local maven
> repo
>
> *** Security Advisory: This Message Originated Outside of AT&T ***.
> Reference http://cso.att.com/EmailSecurity/IDSP.html for more
> information.
>
> 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 <da...@gmail.com>
> > Sent: Tuesday, March 22, 2022 9:50 AM
> > To: Maven Users List <us...@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-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
Re: What steps will install dependent artifacts in local maven repo
Posted by Nick Stolwijk <ni...@gmail.com>.
You are right, I forgot that that still exists. :-S I do think that that
way of dependency management is highly discouraged and IMNSHO should be
discarded in your build as a first step.
With regards,
Nick Stolwijk
~~~ Try to leave this world a little better than you found it and, when
your turn comes to die, you can die happy in feeling that at any rate you
have not wasted your time but have done your best ~~~
Lord Baden-Powell
On Wed, Mar 23, 2022 at 12:05 AM Thomas Broyer <t....@gmail.com> wrote:
> Le mar. 22 mars 2022 à 23:37, Nick Stolwijk <ni...@gmail.com> a
> écrit :
>
> > Also, org.codehaus.groovy:groovy-eclipse-batch:RELEASE is not in
> > Maven Central.
>
>
>
> Yes it is:
> https://search.maven.org/artifact/org.codehaus.groovy/groovy-eclipse-batch
>
> About the RELEASE version:
> https://www.baeldung.com/maven-dependency-latest-version
>
Re: What steps will install dependent artifacts in local maven repo
Posted by Thomas Broyer <t....@gmail.com>.
Le mar. 22 mars 2022 à 23:37, Nick Stolwijk <ni...@gmail.com> a
écrit :
> Also, org.codehaus.groovy:groovy-eclipse-batch:RELEASE is not in
> Maven Central.
Yes it is:
https://search.maven.org/artifact/org.codehaus.groovy/groovy-eclipse-batch
About the RELEASE version:
https://www.baeldung.com/maven-dependency-latest-version
Re: What steps will install dependent artifacts in local maven repo
Posted by Nick Stolwijk <ni...@gmail.com>.
As far as I can see is the support for Java 8 not yet dropped from Groovy
Eclipse. Also, org.codehaus.groovy:groovy-eclipse-batch:RELEASE is not in
Maven Central. Could it be that someone built it locally and uploaded that
artifact to your repository? Maybe you can better rely on the artifacts
provided by Maven Central instead of artifacts built internally?
With regards,
Nick Stolwijk
~~~ Try to leave this world a little better than you found it and, when
your turn comes to die, you can die happy in feeling that at any rate you
have not wasted your time but have done your best ~~~
Lord Baden-Powell
On Tue, Mar 22, 2022 at 11:30 PM KARR, DAVID <dk...@att.com> wrote:
> And I also determined that groovy-eclipse v4.0.1 was released on 3/6/22,
> so it just took a few days to get to our intranet repo. I don't see any
> statement about it being built with Java 11, but it appears that's what
> happened.
>
> > -----Original Message-----
> > From: KARR, DAVID <dk...@att.com>
> > Sent: Tuesday, March 22, 2022 12:15 PM
> > To: Maven Users List <us...@maven.apache.org>
> > Subject: RE: What steps will install dependent artifacts in local maven
> > repo
> >
> > *** Security Advisory: This Message Originated Outside of AT&T ***.
> > Reference http://cso.att.com/EmailSecurity/IDSP.html for more
> > information.
> >
> > 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....@gmail.com>
> > > Sent: Tuesday, March 22, 2022 11:56 AM
> > > To: Maven Users List <us...@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 <dk...@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 <da...@gmail.com>
> > > > > Sent: Tuesday, March 22, 2022 9:50 AM
> > > > > To: Maven Users List <us...@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-unsubscribe@maven.apache.org
> > > > For additional commands, e-mail: users-help@maven.apache.org
> > > >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
RE: What steps will install dependent artifacts in local maven repo
Posted by "KARR, DAVID" <dk...@att.com>.
And I also determined that groovy-eclipse v4.0.1 was released on 3/6/22, so it just took a few days to get to our intranet repo. I don't see any statement about it being built with Java 11, but it appears that's what happened.
> -----Original Message-----
> From: KARR, DAVID <dk...@att.com>
> Sent: Tuesday, March 22, 2022 12:15 PM
> To: Maven Users List <us...@maven.apache.org>
> Subject: RE: What steps will install dependent artifacts in local maven
> repo
>
> *** Security Advisory: This Message Originated Outside of AT&T ***.
> Reference http://cso.att.com/EmailSecurity/IDSP.html for more
> information.
>
> 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....@gmail.com>
> > Sent: Tuesday, March 22, 2022 11:56 AM
> > To: Maven Users List <us...@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 <dk...@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 <da...@gmail.com>
> > > > Sent: Tuesday, March 22, 2022 9:50 AM
> > > > To: Maven Users List <us...@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-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: users-help@maven.apache.org
> > >
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: What steps will install dependent artifacts in local maven repo
Posted by "KARR, DAVID" <dk...@att.com>.
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....@gmail.com>
> Sent: Tuesday, March 22, 2022 11:56 AM
> To: Maven Users List <us...@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 <dk...@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 <da...@gmail.com>
> > > Sent: Tuesday, March 22, 2022 9:50 AM
> > > To: Maven Users List <us...@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-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
Re: What steps will install dependent artifacts in local maven repo
Posted by Thomas Broyer <t....@gmail.com>.
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 <dk...@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 <da...@gmail.com>
> > Sent: Tuesday, March 22, 2022 9:50 AM
> > To: Maven Users List <us...@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-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
RE: What steps will install dependent artifacts in local maven repo
Posted by "KARR, DAVID" <dk...@att.com>.
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 <da...@gmail.com>
> Sent: Tuesday, March 22, 2022 9:50 AM
> To: Maven Users List <us...@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-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org