2

Unfortunately I can't identify what caused this, but after updating my projects, one of the dependencies is not found anymore in the main project. I have no idea why only this causes trouble and none of the others. mvn -U clean package output goes like this:

...
Downloading: http://172.22.1.123:8080/repository/my-snapshots/
com/company/mypkg/dep1/1.4-SNAPSHOT/maven-metadata.xml
Downloaded: http://172.22.1.123:8080/repository/my-snapshots/
com/company/mypkg/dep1/1.4-SNAPSHOT/maven-metadata.xml (993 B at 97.0 KB/sec)
Downloading: http://172.22.1.123:8080/repository/my-snapshots/
com/company/mypkg/dep2/1.7-SNAPSHOT/maven-metadata.xml
Downloaded: http://172.22.1.123:8080/repository/my-snapshots/
com/company/mypkg/dep1/1.7-SNAPSHOT/maven-metadata.xml (993 B at 97.0 KB/sec)
Downloading: http://172.22.1.123:8080/repository/my-snapshots/
com/company/mypkg/dep3/1.2-SNAPSHOT/dep3-1.2-SNAPSHOT.jar
...
[ERROR] Failed to execute goal on project e-backend-impl:
Could not resolve dependencies for project
com.company:dep3:jar:1.2-SNAPSHOT: Could not find artifact
com.company:dep3:jar:1.2-SNAPSHOT in com.company.snapshot.repo
(http://172.22.1.123:8080/repository/my-snapshots) -> [Help 1]

Snapshot repository configuration of Maven's settings.xml is like:

<repository>
  <id>com.company.snapshot.repo</id>
  <name>Company's snapshot repository</name>
  <url>http://172.22.1.123:8080/repository/my-snapshots</url>
  <snapshots>
    <enabled>true</enabled>
    <updatePolicy>always</updatePolicy>
  </snapshots>
  <releases>
    <enabled>false</enabled>
  </releases>
</repository>

Things I tried but didn't help:

  • Installed dep3 in the local repository.
  • while setting updatePolicy to daily or never
  • mvn -o after installing dep3 locally
  • removing the snapshot directory of dep3 in the local repository

Maven version is 3.3.9, Nexus version is 3.12.0. The one hint I can think of is that for dep3, mvn doesn't try to download maven-metadata.xml first, but goes directly for dep3-1.2-SNAPSHOT.jar, which doesn't exist on Nexus because the actual library has a timestamp in the name. But I don't know why this happens and only for dep3, not for dep2 and dep1. It's also a mystery why mvn ignores the locally deployed snapshot.

Any help would be greatly appreciated.

Edit:

Identified a problem with Nexus that has most likely caused it. The main maven-metadata.xml of the project (not the snapshot) doesn't mark the deployed snapshot version as the latest. It looks like this:

<metadata>
  <groupId>com.company.mypkg</groupId>
  <artifactId>dep3</artifactId>
  <versioning>
    <latest>1.1-SNAPSHOT</latest>
    <versions>
      <version>1.0-SNAPSHOT</version>
      <version>1.1-SNAPSHOT</version>
      <version>1.2-SNAPSHOT</version>
    <versions>
    <lastUpdated>20190502080656</lastUpdated>
  </versioning>
</metadata>

Eventually this is also why the local snapshot is also not taken into consideration. Now the question is, how this situation can happen. I've also deployed to Nexus again, but the latest tag still shows the older snapshot version.

Edit 2:

So it works again but I have no idea why. What I did: Deployed dep3 one again to Nexus from our CI. Then, in the dep3 directory:

mvn -U -DupdateReleaseInfo clean install

to see what happens in with the release tag in the local repository (nothing happened, apparently). Then the main project worked. I deleted the dep3 directory in the local repository and it still worked. The maven-metadata.xml in Nexus is still unchanged (latest tag points to an older version). So that was not the problem.

I found this article: https://support.sonatype.com/hc/en-us/articles/213464638-Why-are-the-latest-and-release-tags-in-maven-metadata-xml-not-being-updated-after-deploying-artifacts-

It says the latest field is only set for deploying maven plugins which makes no sense since dep3 is definitely not a maven plugin. The article is very old, however.

  • I'm not sure what the remaining question is (if any) but I can tell you that article you linked is for Nexus Repository Manager 2 thus the age. It shouldn't be relied upon to work the same in version 3 without specifially being told so. – joedragons May 03 '19 at 20:53
  • 1
    Still no idea why it didn't work in the first place, so I guess I can leave the question unanswered. Not 100% sure what to do in this case. I couldn't reproduce the problem afterwards either. – WallaceNC May 06 '19 at 06:53

0 Answers0