Artifactory Maven layout version - jenkins-pipeline

I would like to know what dictates when an artifact is deployed to snapshot vs release repo.
Artifactory has two repos:
libs-snapshot
libs-release
Layout for both:
[orgPath]/[module]/[baseRev](-[folderItegRev])/[module]-[baseRev](-[fileItegRev])(-[classifier]).[ext]
When I run the Jenkins Pipeline the artifacts are always uploaded to libs-release. Note that I do not explicitly put a SNAPSHOT modifier in my pom files. Snapshots have version with build number (e.g. 1.0.0-010) while release only has version (e.g. 1.0.0)
rtMaven.deployer releaseRepo: 'libs-release', snapshotRepo: 'libs-snapshot', server: rtServer
How does the Artifactory plugin decide if it should go to release vs snapshot repo here? Is it the fileItegRev? or folderItegRev?

A snapshot is a version that ends with -SNAPSHOT. It has to be in the path of the artifact to deploy, as gathered by build info extractor.
Relevant code is:
public String getTargetRepository(String deployPath) {
return StringUtils.isNotBlank(snapshotRepo) && deployPath.contains("-SNAPSHOT") ? snapshotRepo : releaseRepo;
}

Related

Build on jenkins and sonatype maven giving me a bad request

When I try to build a maven artifact with Jenkins the build output says the following:
I had already a bunch of successful builds on version 1.0.
I'm using CentOS and Nexus 3 OSS.
400 Bad Request will be returned if you attempt to:
Deploy a snapshot artifact (or version) ending in -SNAPSHOT to a release repository
Deploy a release artifact (version not ending in -SNAPSHOT) to a snapshot repository
Also check: Error when deploying an artifact in Nexus

Gradle maven deployer versioning

We are using Gradle + Maven Plugin to upload jar files to our artifact repository using the following piece of code:
uploadArchives {
repositories {
mavenDeployer {
repository(url: <our maven repo URL>)
pom.groupId = 'group1'
pom.version = '???'
pom.artifactId = 'artifact1'
}
}
}
We set a hook in our CI server that triggers the upload with every push to the master Git repository. I have two questions:
Is that a good idea to automatically upload the jar files on a commit? What's the downside?
How can I give the uploaded jars an automatic new version number, like the latest version plus one? Is that possible to list all the availale versions of an artifact from a maven repo?
It's basically not a bad idea however You need to consider how the dependency is specified for the given artifact - e.g. if some backward incompatible changes were introduced other clients of the uploaded artifact may have problems. So specifying the dependency with + may be problematic and manually switching the version after every release could be tiring. It's good idea to work out why you'd like to upload artifact after every build? Maybe consider uploading artifacts only from a certain branch
Every CI server should pass a build number as a env variable (or system property) to the artifact being built. It's good idea to use this number in automatic versioning. It is possible to download the versions from the repository, but it requires additional work to be done. Download maven-metadata.xml (e.g. this one), parse it, get the latest version and you are almost done.

Importing a snapshot version of a dependency into Maven repository

I am having trouble importing dependencies for my Grails project into the company Nexus repository. The Grails plugin I would like to use is events-push (https://github.com/smaldini/grails-events-push). The latest released version of the plugin is 1.0.M7. It uses a very old version of Atmosphere library. The GutHub repository contains a more up-to-date version of events-push plugin, 1.0.0.BUILD-SNAPSHOT. I built the Grails plugin from the local clone of the repository and got it to work in my dev environment.
To deploy it on the intranet (in the production environment) I need to import all the plugin dependencies into the company Nexus repository. This is where I run into trouble. The project depends on a SNAPSHOT version of events-push plugin, which in turn depends on SNAPSHOT version of other Grails plugins and Java libraries (according to dependency report).
Nexus supports two types of repositories, Release and Snapshot. I can add artifacts to a Release repository (through the browser UI or in a batch mode using curl), but the artifact must not be a snapshot. I can change the repository to be a Snapshot repository, but then I lose the ability to add artifact to it through the browser or curl command.
How do I make these SNAPSHOT artifacts available to the Grails project through Maven?
Change them to a release version and deploy them to the release repository.

deploy on nexus artifacts with Snapshot policy but without SNAPSHOT string in version

apparently my Nexus is rejecting every deploy I throw at him if the artifact has not -SNAPSHOT in the version.
Data:
name of the failing artifact: entando-core-engine-experiment-bundles_with_bootstrap.jar where experiment-bundles_with_bootstrap is the version as in the version element of the pom.xml
hosted repository policy on my Nexus: Snapshot, allow redeploy and so on (classic conf for snapshots)
deployer: Jenkins 1.481
same Jenkins job, but entando-core-engine-SNAPSHOT.jar ---> SUCCESS
I need this naming convention because I'm building one of the several experiments we run internally, as opposite to the canonical develop branch which produces a proper entando-core-engine-SNAPSHOT.jar
Any advice?
I'm totally lost.
The thing is that usually your Nexus is configured not to allow a redeployment of a release. A release from Maven point of view is an artifact where it's version it NOT -SNAPSHOT. In contradiction a SNAPSHOT is intended to be deployed several times into nexus.
This sounds like you don't using the release plugin of Maven nor the Release PLugin of Jenkins.
Nexus is a repository manager that uses different repository formats, with the main format being the Maven repository format. Changing the names of artifacts on the server is not possible since it violates the format. They have to be located in the directory structure established by groupId, artifactId and version and use the artifactId-version-classifier.packaging for the file names.
If you need a different file name on the server you have to look at a different repository format (bad idea). If you need the filename on the client just download from the correct name and rename..

How maven decides to reference the latest artifact information

We use mvn deploy:deploy to deploy an artifact to repository manager and a developer could have done just mvn install for the same artifact, so the artifact is present under M2_HOME\.m2\repository
Will the maven runtime retrieve the artifact from the repository manager if it was updated recently than the local repository copy?
Note: We use a maven repository manager based on Apache Archiva.
The answer depends on whether you're talking about a snapshot or a release build.
Release builds have a version that doesn't end with "-SNAPSHOT", and they're final and immutable. Once installed to any repository, Maven will never update them. To your question, that means that if a dev installs a release build locally, it will never be updated from any remote repository.
Snapshot builds are always eligible to be updated from any repository. By default, Maven checks once per day for new snapshot versions, so if someone installs a snapshot locally, that snapshot will exist until Maven does its next check for snapshot updates. Then, if a newer version is in any remote repository it checks, the local one will be overwritten. You can force maven to update snapshot artifacts with the -U command line option.

Resources