Open mdindoffer opened 4 months ago
looks like ITs not cover your case ... this #219 pass build Can you prepare a reproduce example, which can be added to ITs?
I did not manage to create a reproducible IT, but I made a tiny reproducible project: https://github.com/mdindoffer/gh-221/blob/master/pom.xml
There's literally just an empty pom file with this (for preservation purposes):
mvn clean verify -X
fails with:
<snip>
Caused by: java.lang.NoSuchMethodError: 'void org.apache.maven.scm.command.info.InfoItem.setLastChangedDateTime(java.time.temporal.TemporalAccessor)'
at org.apache.maven.scm.provider.git.jgit.command.info.JGitInfoCommand.getInfoItem (JGitInfoCommand.java:95)
at org.apache.maven.scm.provider.git.jgit.command.info.JGitInfoCommand.executeCommand (JGitInfoCommand.java:68)
at org.apache.maven.scm.command.AbstractCommand.execute (AbstractCommand.java:52)
at org.apache.maven.scm.provider.git.AbstractGitScmProvider.executeCommand (AbstractGitScmProvider.java:257)
at org.apache.maven.scm.provider.git.AbstractGitScmProvider.info (AbstractGitScmProvider.java:266)
at org.codehaus.mojo.build.AbstractScmMojo.info (AbstractScmMojo.java:276)
at org.codehaus.mojo.build.AbstractScmMojo.getScmRevision (AbstractScmMojo.java:285)
at org.codehaus.mojo.build.CreateMojo.getRevision (CreateMojo.java:729)
at org.codehaus.mojo.build.CreateMojo.execute (CreateMojo.java:326)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo (DefaultBuildPluginManager.java:137)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:210)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:156)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:148)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:117)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:81)
at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:56)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:128)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
at org.apache.maven.cli.MavenCli.execute (MavenCli.java:957)
at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:289)
at org.apache.maven.cli.MavenCli.main (MavenCli.java:193)
at jdk.internal.reflect.DirectMethodHandleAccessor.invoke (DirectMethodHandleAccessor.java:103)
at java.lang.reflect.Method.invoke (Method.java:580)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:282)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:225)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:406)
at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:347)
when executed against plugin version 3.2.0.
I tried to use the latest snapshot of 3.2.1, and the repro project builds successfully.
@slawekjaranowski if you could provide some tips on how to convert this to an IT, that'd be great. But it seems to me as if your ITs were not designed to specifically cross-test dependency compatibilities, since you just always execute against the latest set of maven properties. You know, the fact that the latest snapshot works OK, while 3.2.0 is failing is telling me that at some point some commit in the unreleased snapshot fixed this classpath/incompatibility issue. Therefore it's not too surprising that your dependabot merge request passed successfully, since there was a bunch of preceding commits updating the rest of the libs.
Oh actually, I took a second look, and it's pretty simple really.
maven-scm-provider-jgit
2.1.0 depends on maven-scm-provider-git-commons
, and is calling setLastChangedDateTime
which is implemented @since 2.1.0
.
All the while buildnumber-maven-plugin
3.2.0 is pulling in maven-scm-provider-git-commons
in version 2.0.1.
The reason why your CI pipelines did not break is because you first merged #219 which updated the git commons.
This is (strictly speaking) a breaking change in jgit provider, but there isn't any documentation on how to actually use the git provider with the buildnumber plugin, so I assumed it's just enough to pull the provider dependency explicitly. Turns out you have to pull git-commons as well.
Still, the point of the issue stands, buildnumber-maven-plugin
3.2.0 is not compatible with jgit provider 2.1.0 out of the box. Snapshots do work, a release should be made imho.
ok, I will release next version hope will resolve your issue added to my release queue 😄
Summary
buildnumber-maven-plugin 3.2.0 fails to execute the
create
goal with the latestjgit
provider implementation, likely due to a breaking API change.Environment: