Now that Maven3 has dropped support for setting uniqueVersion=false on deployment, I'm running into an issue. I have Hudson do an automatic deployment of my SNAPSHOT build to my Nexus repository manager. The resulting SNAPSHOT artifact looks like blah-0.0.1-20110517.233746-1.jar. Note the unique SNAPSHOT build id. The trick is that I'd link to that jar in my site documentation, but I'm not sure how to inject that snapshot build number into the docs. Perhaps there is a way to have Maven or Hudson or Nexus create a symlink on deployment from blah-0.0.1.jar => blah-0.0.1-20110517.233746-1.jar?
Ok, mod me down, but I think I found an answer to my own question. I'm posting here in case anyone else finds it useful.
It turns out the Nexus REST api has the ability to automatically retrieve the latest SNAPSHOT build of an artifact, which is exactly the functionality I needed. For more info, see:
https://docs.sonatype.com/display/SPRTNXOSS/Nexus+FAQ#NexusFAQ-Q.HowcanIretrieveasnapshotifIdon%27tknowtheexactfilename%3F
Related
In the AWS CodeBuild pipeline I got this error during the build-image task:
could not download https://repo.spring.io/release/org/springframework/cloud/spring-cloud-bindings/1.10.0/spring-cloud-bindings-1.10.0.jar
The same build fail on my PC and the artifact spring-cloud-bindings-1.10.0.jar doesn't exists anymore on repo.spring.io.
Today the build-image task is working and the spring-cloud-bindings-1.10.0.jar is available from url https://repo.spring.io/release/org/springframework/cloud/spring-cloud-bindings/1.10.0/spring-cloud-bindings-1.10.0.jar.
The problem cause was a spring repo temporary unavailability.
This is an evidence this task doesn't use maven repository cache mechanism.
For future readers having the same or similar issues, you might want to read the relevant article from Spring team here.
Basically the sum up of the article is, that you better stop retrieving dependencies from repo.spring.io and switch to maven central instead.
Reason is that the instance of repo.spring.io was sponsored in the past from JFrog, Inc but as the situation has now changed they are basically moving to other instances.
I see that you can add a goal to a maven Pom to archive artifacts to a repo manager such as nexus
https://www.baeldung.com/maven-deploy-nexus
distributionManagement>
<snapshotRepository>
<id>nexus-snapshots</id>
<url>http://localhost:8081/nexus/content/repositories/snapshots</url>
</snapshotRepository>
</distributionManagement>
But Jenkins also allows you to do this from the pipeline itself
https://wiki.jenkins.io/plugins/servlet/mobile?contentId=96076078#content/view/96076078
freeStyleJob('NexusArtifactUploaderJob') {
steps {
nexusArtifactUploader {
nexusVersion('nexus2')
protocol('http')
nexusUrl('localhost:8080/nexus')
groupId('sp.sd')
version('2.4')
repository('NexusArtifactUploader')
credentialsId('44620c50-1589-4617-a677-7563985e46e1')
artifact {
artifactId('nexus-artifact-uploader')
type('jar')
classifier('debug')
file('nexus-artifact-uploader.jar')
}
artifact {
artifactId('nexus-artifact-uploader')
type('hpi')
classifier('debug')
file('nexus-artifact-uploader.hpi')
}
}
}
}
What is the difference between the two approaches, is one more commonly used?
The main difference is that if you use maven, you can manually add artifacts to Nexus from your local computer, using mvn deploy. So it really comes down to how you want to create the artifacts that end up being used in production. In my experience, the preferred way of doing this is through using Jenkins. The advantage of using Jenkins is that you link your new version builds to other activities, as well as the possibility to trigger a release when certain conditions have been met, rather than starting the build manually. Also, you end up with all versions being built on the same platform, and you avoid differences between computers if every developer builds such versions from their own computer.
But you might still need the maven configuration. Jenkins might use this information to find the URL to upload the artifact to (your example says nothing about how Jenkins finds Nexus), and sometimes it is useful to upload a SNAPSHOT-version, or some other temporary version not meant for production. In your example you only define Nexus for upload SNAPSHOT-versions, I guess this is done on purpose to enforce a rule that uploading final version from local computers is disallowed.
By the way, having a repository defined in your pom.xml does not automatically mean that anything will be uploaded. It is only if you do mvn deploy with a repository defined in your pom that something will be uploaded.
We're deploying our open source libraries to the OSS instance of Sonatype Nexus (https://oss.sonatype.org/) using the nexus-staging-plugin. This works all fine and well. However, since we're using a build server I want to block an accidential re-deployment of an existing artifact id - as this is normally not suppoted by maven. However, the OSSRH happily accepts and updates an existing release. Is there any way to block this and make the build fail?
I know that Nexus can be configured to do that - it is just, that I don't have any permissions to reconfigure the OSSRH instance..
Is there any maven plugin which could check the repo first and fail in first place in case nexus/sonatype does not support this? I looked into the enforcer plugin but there isn't a rule available.
It is true that there is a staging rule in Nexus which prevents duplicate GAV's being staged, but it is not enabled on https://oss.sonatype.org. The reason for this is that some users stage artifacts repeatedly (creating multiple staging repositories) and then choose one of them for release based on testing results.
But the server at https://oss.sonatype.org is configured so that you cannot release the same artifacts twice. So if you have two staging repositories that contain the same artifacts you will only be able to release one of them.
Currently a Maven build (inside Jenkins) is configured to deploy every artifact it builds (releases and snapshots) to a Nexus repository. Now I have to push some of those artifacts to application servers and thought of letting the target servers fetch them from Nexus - this is easy for releases but how can I reference the SNAPSHOT artifacts? Maven's deploy plugin adds a timestamp to make each artifact unique (which is good) but I couldn't find a way to get that generated timestamp for later use!
Quick Aside: I plan to use the promoted builds plugin to start a script on the target server(s) which then in turn ask Nexus for the new artifact to deploy.
Does anybody know how I can make Maven say the timestamp it generates? Or do I really have to parse the whole output for Uploaded: https://NEXUS_URL/content/repositories/snapshots/GROUP/ARTIFACT/VERSION/ARTIFACT-VERSION-TIMESTAMP-SUFFIX.TYPE?
As far as I know you do need to parse the output of the deploy goal.
I have a Maven plugin that I want to share with outside world. Is there an official Maven repository I can deploy this plugin too ? What are the steps involved ?
Any links to documentation much appreciated
I've been reading http://www.sonatype.com/people/2008/11/adding-a-jar-to-a-maven-repository-with-sonatype-nexus/ but this just seems to describe deploying to internal Nexus repository, wheras I want to deploy to an external repo so any user can use it.
I would recommend:
Setting up an account in Github in order to have a place to host your source code.
Setting up an account in Cloudbee's BuildHive. This is a free Jenkins CI for Open Source projects. This will test your project on every push to Github.
Request rights to publish your project to Maven Central.
The bit with the request will take around up to a day normally and then you'll be able to publish your code directly to Maven Central.