Issue
I'm looking for a way to upload and store multiple versions of an artifact to the Sonatype Nexus maven-2 repository, so a team has access to previous versions of the artifact if a new version was released and uploaded.
I upload a java library to the hosted maven-2 release repository. Everything works well until I upload another version of the same library to the same repository. After uploading the second version all files are present in the repository, but Maven cannot resolve not first nether second versions.
I tried both ways to upload artifacts - manually with the nexus UI and using the Maven deploy command. Results are the same.
I believe there is a way to store multiple versions in one repository. Is there a special configuration for that case?
Please, help me to figure out how can I solve this issue.
As I mentioned, I have all settings that allow me to deploy and download one artifact from nexus.
In the library pom.xml I have:
<groupId>com.company.lib</groupId>
<artifactId>LibName</artifactId>
<version>1.0.7</version>
<name>LibName</name>
...
<distributionManagement>
<repository>
<id>testdeploy</id>
<url>https://nexus.company.com/repository/testdeploy/</url>
</repository>
</distributionManagement>
In the project where I want to download a library I have:
<dependencies>
<dependency>
<groupId>com.company.lib</groupId>
<artifactId>LibName</artifactId>
<version>1.0.7</version>
</dependency>
</dependencies>
<repositories>
<repository>
<id>testdeploy</id>
<url>https://nexus.company.com/repository/testdeploy/</url>
<snapshots>
<enabled>true</enabled>
</snapshots>
</repository>
</repositories>
In settings.xml I have:
<servers>
<server>
<id>testdeploy</id>
<username>...</username>
<password>...</password>
</server>
<servers>
<mirrors>
<mirror>
<id>nexus</id>
<mirrorOf>*</mirrorOf>
<url>https://nexus.company.com/repository/maven-public</url>
<name>Nexus M2</name>
</mirror>
<mirror>
<id>central_new</id>
<mirrorOf>central</mirrorOf>
<url>https://repo.maven.apache.org/maven2</url>
</mirror>
</mirrors>
<profiles>
<profile>
<id>release</id>
<repositories>
<repository>
<id>testdeploy</id>
<name>custom repo</name>
<url>https://nexus.company.com/repository/testdeploy/</url>
</repository>
</repositories>
</profile>
</profiles>
After uploading two versions of the library to nexus I have the following file structure:
com
company
lib
LibName
1.0.6
LibName-1.0.6.jar
LibName-1.0.6.jar.md5
LibName-1.0.6.jar.sha1
LibName-1.0.6.pom
LibName-1.0.6.pom.md5
LibName-1.0.6.pom.sha1
1.0.7
LibName-1.0.7.jar
LibName-1.0.7.jar.md5
LibName-1.0.7.jar.sha1
LibName-1.0.7.pom
LibName-1.0.7.pom.md5
LibName-1.0.7.pom.sha1
maven-metadata.xml
maven-metadata.xml.md5
maven-metadata.xml.sh1
When I try to download any of these versions via Maven I get an error
"Could not find artifact com.company.lib:LibName:1.0.6 in nexus (nexus.company.com/repository/maven-public)"
Solution:
In my case there were two problems:
- The "testdeploy" repository was not added in maven-public group.
- The "testdeploy" repo was made to test deployment artifact's versions from maven. I wanted to deploy another version of the library into the real repo after testing. The problem was that the real repo still had the library with the same artifact id and version. So there was a conflict between the real repo and test repo ("testdeploy") even after adding the "testdeploy" version into the "maven-public" group. To test deployment I had to change the librarie's artifact id.
Once these two issues were solved I didn't need to specify "testdeploy" repository in pom.xml. Defining the settings of the mirror (maven-public) and the server credentials in settings.xml were enough to make it work.
Solution
Maven identifies a unique artifact by a combination of 3 values: the groupId, the artifactID and the version. Appending -SNAPSHOT
to a version has some additional special behaviour described here
The unique identifier for your artifact per your first pom snippet, would be
com.company.lib:LibName:1.0.7
If you want different addressable artifacts, change the version number. If people are still using the original 1.0.7
you should be producing 1.0.8
or some other incremented version.
Worth noting that projects that build in this often use SemVer and it's a convention that works in well understood ways so is probably a safe place to start.
EDIT TO ADD:
Based on comments, and re-review it looks like whatever is trying to pull 1.0.6 is not doing so from https://nexus.company.com/repository/testdeploy/
. Instead it's trying to pull from nexus.company.com/repository/maven-public
and failing.
For the project trtying to pull 1.0.6 what is the repository config? Your settings.xml
only adds the testdeploy
repo if the releases
profile is active, so the testdeploy
repo would need to be called out in the pom.
Answered By - Taylor
Answer Checked By - Cary Denson (JavaFixing Admin)