6

We've been seeing a bug recently where Maven tries to retrieve a SNAPSHOT that doesn't exist. As you can see the build number (whatever that is, because it's not our build number) matches, but the timestamp doesn't, causing the build to fail. This happens once in every say 20 builds.

This is in Nexus: In nexus

And this is what happens during the build:

Artifacts not found

As you can see it tries to retrieve relations-models:jar:1.1-20170901.134955-278 which doesn't exist, while 20170901.134954-278 does. Notice the offset of one second.

  1. Does anyone else have this problem? And a workaround?
  2. I was thinking of replacing the timestamp with the build number, but I can't find a way to influence how snapshots are suffixed. Does anyone know how to do that?

This concerns a (big) multi-module project, where this is one of the sub-modules.

The Jar plugin is configured like this

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-jar-plugin</artifactId>
    <configuration>
        <archive>
            <manifest>
                <addClasspath>true</addClasspath>
                <classpathPrefix>lib/</classpathPrefix>
                <mainClass>me.magnet.redirect.RedirectService</mainClass>
                <useUniqueVersions>false</useUniqueVersions>
                <classpathLayoutType>custom</classpathLayoutType
 <customClasspathLayout>$${artifact.artifactId}-$${artifact.baseVersion}.$${artifact.extension}</customClasspathLayout>
            </manifest>
        </archive>
    </configuration>
</plugin>

And the deploy plugin like this:

<plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-deploy-plugin</artifactId>
        <version>2.8.2</version>
        <configuration>
            <uniqueVersion>false</uniqueVersion>
            <deployAtEnd>true</deployAtEnd>
        </configuration>
</plugin>

The build runs in parallel too.

aSemy
  • 5,485
  • 2
  • 25
  • 51
Alex
  • 2,953
  • 1
  • 27
  • 37
  • Does maven-metadata.xml show the correct version? – Ferrybig Sep 06 '17 at 15:49
  • 2
    The suffix is a Maven standard. It is probably a bad idea to change it (if it is possible at all). Show us your pom so we can find out why this offset occurs. – J Fabian Meier Sep 06 '17 at 15:54
  • Does this issue happen within a multi module build or does it happen having on build producing the artifacts whereas an other build is consuming it? Are those builds running in parallel ? – khmarbaise Sep 06 '17 at 20:08
  • Updated the question to answer your questions. – Alex Sep 07 '17 at 07:56
  • Also I'm pretty sure (but forgot to check at the time) that the `maven-matedata.xml` has the wrong artifact name. So my hunch is that because of the parallel build, and the `deployAtEnd` config, it takes a new timestamp instead of using the one it already communicated to the `maven-matedata.xml` – Alex Sep 07 '17 at 07:57
  • This would seem like a bug in Maven, or one of the plugins ainvolved. Which version of Maven, the `maven-jar-plugin` and `maven-deploy-plugin` are you using? Basically, when deploying a timestamped artifact, Maven must guarantee that all of the artifact's sub-artifact files (pom + classifier-based artifacts) will have the same timestamp and build number. From what I can tell, the timestamp is off by a few milliseconds, while the build number looks correct. This difference is what is breaking things. This difference seems to be only in the produced and uploaded `maven-metadata.xml`. – carlspring Sep 27 '17 at 11:47
  • If this was produced and uploaded by Maven, then it's a bug in the `maven-deploy-plugin`. If the metadata has been rebuilt by Nexus, then it is a bug in your version of Nexus. – carlspring Sep 27 '17 at 11:52

1 Answers1

1

Maven will try to download the latest snapshot version listed in the maven-metadata.xml file in the repository.

It sounds like you have this version listed in the maven-metadata.xml but the file is actually not there. This could possibly be due to incomplete uploaded build; if e.g. multiple modules are trying to use exact same spanshot version number, but some of them failed to compile and were not uploaded to the repo. ( also, possibly incorrect maven pom.xml configuration )

Zilvinas
  • 5,518
  • 3
  • 26
  • 26