Re: What steps will install dependent artifacts in local maven repo
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 wrote: > Le mar. 22 mars 2022 à 23:37, Nick Stolwijk 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
Le mar. 22 mars 2022 à 23:37, Nick Stolwijk 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
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 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
> > Sent: Tuesday, March 22, 2022 12:15 PM
> > To: Maven Users List
> > Subject: RE: What steps will install dependent artifacts in local maven
> > repo
> >
> > *** Security Advisory: This Message Originated Outside of AT ***.
> > Reference http://cso.att.com/EmailSecurity/IDSP.html for more
> > information.
> >
> > Here is the maven-compiler-plugin block:
> >
> >
> >
> maven-compiler-plugin
> >
> ${maven.compiler.plugin.version}
> >
> >
> > compile
> >
> >
> >
> >
> >
> org.codehaus.groovy
> > groovy-eclipse-
> > compiler
> > 3.7.0
> >
> >
> >
> org.codehaus.groovy
> > groovy-eclipse-
> > batch
> > RELEASE
> >
> >
> >
> > groovy-eclipse-
> > compiler
> >
> >
> > --
> >
> > 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
> > > Sent: Tuesday, March 22, 2022 11:56 AM
> > > To: Maven Users List
> > > 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 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
> > > > > Sent: Tuesday, March 22, 2022 9:50 AM
> > > > > To: Maven Users List
> > > > > 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
> >
RE: What steps will install dependent artifacts in local maven repo
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
> Sent: Tuesday, March 22, 2022 12:15 PM
> To: Maven Users List
> Subject: RE: What steps will install dependent artifacts in local maven
> repo
>
> *** Security Advisory: This Message Originated Outside of AT ***.
> Reference http://cso.att.com/EmailSecurity/IDSP.html for more
> information.
>
> Here is the maven-compiler-plugin block:
>
>
> maven-compiler-plugin
>
> ${maven.compiler.plugin.version}
>
>
> compile
>
>
>
>
>
> org.codehaus.groovy
> groovy-eclipse-
> compiler
> 3.7.0
>
>
>
> org.codehaus.groovy
> groovy-eclipse-
> batch
> RELEASE
>
>
>
> groovy-eclipse-
> compiler
>
>
> --
>
> 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
> > Sent: Tuesday, March 22, 2022 11:56 AM
> > To: Maven Users List
> > 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 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
> > > > Sent: Tuesday, March 22, 2022 9:50 AM
> > > > To: Maven Users List
> > > > 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
RE: What steps will install dependent artifacts in local maven repo
Here is the maven-compiler-plugin block:
maven-compiler-plugin
${maven.compiler.plugin.version}
compile
org.codehaus.groovy
groovy-eclipse-compiler
3.7.0
org.codehaus.groovy
groovy-eclipse-batch
RELEASE
groovy-eclipse-compiler
--
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
> Sent: Tuesday, March 22, 2022 11:56 AM
> To: Maven Users List
> 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 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
> > > Sent: Tuesday, March 22, 2022 9:50 AM
> > > To: Maven Users List
> > > 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
RE: What steps will install dependent artifacts in local maven repo
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 > Sent: Tuesday, March 22, 2022 11:20 AM > To: Maven Users List > Subject: RE: What steps will install dependent artifacts in local maven > repo > > *** Security Advisory: This Message Originated Outside of AT ***. > 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 > > Sent: Tuesday, March 22, 2022 9:50 AM > > To: Maven Users List > > 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
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 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 > > Sent: Tuesday, March 22, 2022 9:50 AM > > To: Maven Users List > > 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 >
RE: What steps will install dependent artifacts in local maven repo
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 > Sent: Tuesday, March 22, 2022 9:50 AM > To: Maven Users List > 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
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.
