MVN release fails with "Repository does not allow updating assets: releases" when it should not - maven

We have a multi module project for which we want to do a release using the following command
mvn release:prepare release:perform -B -e -X
which fails with
07:54:12 [INFO] Caused by: org.eclipse.aether.transfer.ArtifactTransferException:
Could not transfer artifact ch.test.sub:my-app:pom:2019.02.07 from/to
release-repo (https://nexus.intra/content/repositories/releases/):
Failed to transfer file:
https://nexus.intra/content/repositories/releases/ch/test/sub/my-app/2019.02.07/my-app-2019.02.07.pom.
The return code is 400, ReasonPhrase: Repository does not allow updating assets: releases.
The message is pretty clear but there are some things which do not add up
When initiating maven the my-app-2019.02.07.pom is not in nexus
I examined the log and there is only one "Uploading to release-repo" happening which is when the build process fails with the message above
07:54:11 [INFO] [INFO] Uploading to release-repo:
https://nexus.intra/content/repositories/releases/ch/test/sub/my-
app/2019.02.07/my-app-2019.02.07.pom
At this point, I can observe that there is a my-app-2019.02.07.pom in the Nexus repository
How does it get there when - according to the log - there was no upload happening?
pom.xml before maven is initiated
...
<parent>
<groupId>ch.test</groupId>
<artifactId>my.app</artifactId>
<version>2019.02.07-SNAPSHOT</version>
<relativePath>../pom-parent</relativePath>
</parent>
...
Version Info
Apache Maven 3.5.4
Java version: 1.8.0_201
OS name: "windows server 2016", version: "10.0", arch: "amd64", family: "windows"

I hit this issue and resolved by manually deleting the uploaded pom file, in my case it hit issues after the pom upload, causing the release to fail. Subsequent attempts at mvn release:perform then failed as that pom already existed.
Another approach to fixing this is documented here Gradle Upload Fails But Still Deploys to Nexus

Related

Error when creating Maven project from archetype: 501 HTTPS Required

I run mvn archetype:generate and get this error:
Error reading archetype catalog http://repo.maven.apache.org/maven2
org.apache.maven.wagon.TransferFailedException: Transfer failed for http://repo.maven.apache.org/maven2 501 HTTPS Required
I'm using Maven 3.6.3.
I cannot put a different repository URL into the POM file, because when I'm creating a project from an archetype, no POM file exists yet.
I have no settings.xml file in ~/.m2.
Is there something wrong with my Maven installation?
The output of mvn --version is:
Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)
Maven home: /usr/local/Cellar/maven/3.6.3_1/libexec
Java version: 11.0.2, vendor: Oracle Corporation, runtime: /Library/Java/JavaVirtualMachines/jdk-11.0.2.jdk/Contents/Home
Default locale: en_US, platform encoding: UTF-8
OS name: "mac os x", version: "10.14.6", arch: "x86_64", family: "mac"
/usr/local/Cellar/maven/3.6.3_1/libexec/conf/settings.xml does not contain the URL that the error message is complaining about.
Short answer: override the default http catalog url with an https one, by appending:
-DarchetypeCatalog=https://repo.maven.apache.org/maven2/archetype-catalog.xml
to the mvn archetype:generate command
Background:
When using the mvn -X -e archetype:generate command, Maven 3.6.3 seems to use version 2.4 of the maven-archetype-plugin:
[DEBUG] Resolved plugin version for org.apache.maven.plugins:maven-archetype-plugin to 2.4 from repository central (https://repo.maven.apache.org/maven2, default, releases)
The plugin uses the remote catalog: http://repo.maven.apache.org/maven2/archetype-catalog.xml:
[DEBUG] Searching for remote catalog: http://repo.maven.apache.org/maven2/archetype-catalog.xml
[DEBUG] Searching for remote catalog: http://repo.maven.apache.org/maven2
[WARNING] Error reading archetype catalog http://repo.maven.apache.org/maven2
org.apache.maven.wagon.TransferFailedException: Transfer failed for http://repo.maven.apache.org/maven2 501 HTTPS Required
As of 15/1/2020, maven central requires an HTTPS url: Central 501 HTTPS Required
According to this JIRA, the issue should be fixed in version 3.0.0 of the plugin.

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

Using mvn get to pull latest artifact from Nexus repository

I am trying to pull the latest artifact from my Nexus repository. I am using the get command to pull the artifact.
mvn dependency:get -Durl=http://nexus-repository:8080/nexus/content/repositories/snapshots -Dartifact=com.my.company:common:LATEST-Dtransitive=false -Ddest=. -s settings.xml
And it is the error message I am getting.
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-dependency-plugin:2.8:get (default-cli) on project standalone-pom: Couldn't download artifact: Failed to resolve version for com.my.company:common:jar:LATEST: Could not find metadata com.my.company:common/maven-metadata.xml in releases (http://nexus-repository:8080/nexus/content/repositories/releases)
I do not know either why it is looking on release and not in snapshots because the version is on my snapshots repository.
When I run with the specific version everything works fine:
mvn dependency:get -Durl=http://nexus-repository:8080/nexus/content/repositories/snapshots -Dartifact=com.my.company:common:1.0.0-SNAPSHOT -Dtransitive=false -Ddest=. -s settings.xml
I will like to pull the latest version using mvn command and not curl neither wget.
Any recommendation or idea?

pom-only artifact unexpectedly deployed as jar to Artifactory

I have a multi-module project with a root pom.xml, defined with <packaging>pom</packaging>, and several <modules>.
On Jenkins, I run maven with the goals jar:jar install:install -Dmaven.test.skip=true (compiling and testing was already done by previous jobs in the build pipeline).
As a post-build action, I deploy artifacts to Artifactory. I checked 'Deploy Maven artifacts' and left include/exclude blank so it will take the defaults.
The submodules correctly have their pom and jar deployed to Artifactory. I see this in the console output:
Deploying artifacts of module: com.example:foo
Deploying artifact: https://repo.example.com/snapshot/com/example/foo/7.0.0-SNAPSHOT/foo-7.0.0-SNAPSHOT.jar
Deploying artifact: https://repo.example.com/snapshot/com/example/foo/7.0.0-SNAPSHOT/foo-7.0.0-SNAPSHOT.pom
The root pom is not correctly uploaded to Artifactory.
When "Supress POM Consistency Checks" is off, the build fails with a conflict on the root pom:
Deploying artifacts of module: com.example:root
Deploying artifact: https://repo.example.com/snapshot/com/example/root/7.0.0-SNAPSHOT/root-7.0.0-SNAPSHOT.pom
ERROR: Failed to deploy file: HTTP response code: 409. HTTP response message: Conflict
java.io.IOException: Failed to deploy file: HTTP response code: 409. HTTP response message: Conflict
at org.jfrog.build.extractor.clientConfiguration.client.ArtifactoryBuildInfoClient.throwHttpIOException(ArtifactoryBuildInfoClient.java:743)
at org.jfrog.build.extractor.clientConfiguration.client.ArtifactoryBuildInfoClient.uploadFile(ArtifactoryBuildInfoClient.java:623)
at org.jfrog.build.extractor.clientConfiguration.client.ArtifactoryBuildInfoClient.deployArtifact(ArtifactoryBuildInfoClient.java:329)
at org.jfrog.hudson.maven2.ArtifactsDeployer.deployArtifact(ArtifactsDeployer.java:190)
at org.jfrog.hudson.maven2.ArtifactsDeployer.deploy(ArtifactsDeployer.java:130)
at org.jfrog.hudson.ArtifactoryRedeployPublisher.perform(ArtifactoryRedeployPublisher.java:420)
at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20)
at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:782)
at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:723)
at hudson.maven.MavenModuleSetBuild$MavenModuleSetBuildExecution.post2(MavenModuleSetBuild.java:1047)
at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:668)
at hudson.model.Run.execute(Run.java:1763)
at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:531)
at hudson.model.ResourceController.execute(ResourceController.java:98)
at hudson.model.Executor.run(Executor.java:410)
Build step 'Deploy artifacts to Artifactory' changed build result to FAILURE
When "Supress POM Consistency Checks" is on, I check root on Artifactory and I go to "POM View", then I see binary garble starting with "PK", which indicates a ZIP file or in this case probably a JAR file. Downloading that file and extracting as zip confirmed that it contains a META-INF directory with some subdirectories related to Maven.
What I was expecting, was a plain text pom.xml for root.
I also noticed this in the console log:
[JENKINS] Archiving /var/lib/jenkins/jobs/example-develop-maven-artifactory/workspace/target/example-root-7.0.0-SNAPSHOT.jar to com.example/root/7.0.0-SNAPSHOT/root-7.0.0-SNAPSHOT.pom
and then
Deploying artifacts of module: com.example:root
Deploying artifact: https://repo.example.com/snapshot/com/example/root/7.0.0-SNAPSHOT/root-7.0.0-SNAPSHOT.pom
Deploying artifact: https://repo.example.com/snapshot/com/example/root/7.0.0-SNAPSHOT/root-7.0.0-SNAPSHOT.pom
As I understand it, Artifactory intercepts what the build tool deploys in the local repository (~/.m2).
How do I get the pom, and only the pom, and no magically generated jar, of my root, on Artifactory? Which probably boils down to, how do I tell Maven and/or Jenkins not to overwrite my root pom with a root jar?
Versions:
Artifactory 3.4.2 (rev. 30140)
Jenkins 1.643
Artifactory Plugin 2.4.7
Starting from #khmarbaise's comment, I am now running the build with
mvn install \
-Dmaven.main.skip=true \
-Dcheckstyle.skip=true \
-Dfindbugs.skip=true \
-Dmaven.test.skip=true \
-Dmaven.site.skip=true \
-Dmaven.javadoc.skip=true
The build still takes 54 seconds, which is unfortunate, but there isn't Yet Another Redundant Compilation, which is exactly what I want.
The pom-only root is correctly deploted to Artifactory.

maven deploy:deploy-file fails (409 Conflict), yet artifact uploads successfully

NOTE:
I now realize that the jar got placed into my repository, but the pom.xml did not. Now, I have another project where the pom.xml fails to get promoted, but the jar is placed in the repository.
However, another project, both the pom.xml and the jar do get placed in the repository.
I have a project in Jenkins where I use the promotion plugin to deploy my artifacts in Maven via the deploy:deploy-file goal.
This works for several other projects I have in Maven, but it fails for this project. The funny thing is that the file (but not the pom.xml) uploads anyway. I've verified this by removing the artifact from our Maven repository, then running the promotion. The artifact is in our repository after the promotion.
Here's the log I'm getting. Broke up the extra long lines the best I could:
[workspace] $ /bin/bash -xe /opt/tomcat/apache-tomcat-7.0.27/temp/hudson7357923598740079329.sh
+ FILE_LOC=/mnt/jenkins/builds/metricsdb-trunk/21/archive/target/archive
+ mvn deploy:deploy-file
-Dversion=0.8.0
-Dfile=/mnt/jenkins/builds/metricsdb-trunk/21/archive/target/archive/metricsdb-etl.jar
-DpomFile=/mnt/jenkins/builds/metricsdb-trunk/21/archive/target/archive/pom.xml
-Durl=http://repo.vegicorp.com/artifactory/ext-release-local -DrepositoryId=VegiCorp
[INFO] Scanning for projects...
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building Command Line Spring Batch Module 0.8.0.CI-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- maven-deploy-plugin:2.7:deploy-file (default-cli) # metricsdb-etl ---
Uploading: http://repo.vegicorp.com/artifactory/ext-release-local/com/vegicorp/batch/metricsdb/metricsdb-etl/0.8.0/metricsdb-etl-0.8.0.jar
2/38 KB
4/38 KB
[...]
Uploaded: http://repo.vegicorp.com/artifactory/ext-release-local/com/vegicorp/batch/metricsdb/metricsdb-etl/0.8.0/metricsdb-etl-0.8.0.jar (38 KB at 202.2 KB/sec)
Uploading: http://repo.vegicorp.com/artifactory/ext-release-local/com/vegicorp/batch/metricsdb/metricsdb-etl/0.8.0/metricsdb-etl-0.8.0.pom
2/7 KB
4/7 KB
[...]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 1.243s
[INFO] Finished at: Thu Oct 04 14:38:52 CDT 2012
[INFO] Final Memory: 4M/119M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-deploy-plugin:2.7:deploy-file
(default-cli) on project metricsdb-etl: Failed to deploy artifacts:
Could not transfer artifact com.vegicorp.batch.metricsdb:metricsdb-etl:pom:0.8.0 from/to
VegiCorp (http://repo.vegicorp.com/artifactory/ext-release-local):
Failed to transfer file: http://repo.vegicorp.com/artifactory/ext-release-local/com/vegicorp/batch/metricsdb/metricsdb-etl/0.8.0/metricsdb-etl-0.8.0.pom.
Return code is: 409, ReasonPhrase:Conflict. -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
failed build hudson.tasks.Shell#24a6e7f9 SUCCESS
Finished: FAILURE
Output with the debug flag (-X) is in Pastebin.
I found the problem. Two problems actually:
I only had the release repository setup, and I was attempting to save a snapshot release in the release repository. Artifactory was setup to only allow releases in the release repository. This can be modified in the Artifactory setting, but I decided against this.
My pom.xml has a different version in it than I was trying to save it to. For example, the pom.xml said version 2.0 and I was trying to save the release as 2.0.2. Artifactory rejected the pom (but not the jar) for this reason.
I found the Artifactory setting (which is per repository) that asks whether or not to "Suppress POM consistency checks". Checking this box will allow me to set the version to one, but have the pom say another.
I also had to modify my Maven "settings.xml" file to allow for both a Release and Snapshot repository. I also have to modify my URL to the snapshot repository.
We were only using Ivy for a while (which doesn't have a snapshot concept), so we were just putting stuff in the release repository. This is a Maven project, and the developer marked the version in the POM as a SNAPSHOT.
Unfortunately, Maven documentation is pretty poor, and there still aren't any good books on Maven. Even worse is that the error messages are simply poor. What does "409, ReasonPhrase:Conflict. -> [Help 1]" mean?
Not that Ivy documentation is so much better, but Ant in Action has some excellent sections on using Ivy.
Ensure that you include -SNAPSHOT as part of your version if you are publishing to the snapshot repository.
And remove -SNAPSHOT in case you are publishing it to a non-snapshot repository.
Yeah....Multiple Reason for same error. May be it will help somebody
1. Login as Admin to Artifactory
2. Configuration -> Repositories
3. Edit the Local Repository ---> Suppress POM Consistency Checks
This solves my problem.... Not sure. Right approach or not ?
I also face this problem, and I found the reason is the parent project didn't deploy in the snapshot repository.
I run mvn deploy in the parent folder, and the problem resolved.
Had that error message too. For me the problem was that the setup of the server is to accept only release, not SNAPSHOT. After removing the SNAPSHOT from the pom, it worked fine.
In my case the POM file associated with the jar file (external, in same dir) had a dependency to itself. This was a offline zipped repo from a third party that I needed to load into artifactory.
I modified the POM files, removed the self-dependency and made sure the package info was right. Then artifacts deployed with no problems. Sent email to vendor so they can fix in their build.
I had this issue as well and it turned out that we had include/exclude rules set up on the repository I was trying to deploy to and my deployment didn't match those rules.
My solution was to point the deployment at a new repository that had **/* as the include rule (and the pattern from my other repository as an exclude rule to keep them separate).
I have been experiencing the same problem.
(TL;DR: solution see last line)
During the deploy from jenkins to Artifactory, sometimes (magic!) a 409 - conflict error appeared with the following error message on the Artifactory log:
[WARN ] (o.a.e.UploadServiceImpl:239) - Sending HTTP error code 409: Checksum policy 'LocalRepoChecksumPolicy: CLIENT' rejected the artifact 'gradle-integration:com.redacted.java/fooProject/123/foo-123.jar'. Checksums info: ChecksumsInfo{checksums={SHA-1=ChecksumInfo{type=SHA-1, original='da39a3ee5e6b4b0d3255bfef95601890afd80709', actual='1459689f0be058f4ecef7e6fe3576f1550a8afda'}, MD5=ChecksumInfo{type=MD5, original='d41d8cd98f00b204e9800998ecf8427e', actual='14c7a498de028d6eb5882b3c698bc456'}}}.
As the trained eye might notice: The MD5# d41d8cd98f00b204e9800998ecf8427e is the checksum for an empty file or string.
Which means that the following must be happening:
The copy job that prepares the Artifacts in the publish folder had not finished and therefore the file was empty when the checksum was calculated.
However when the deploy happened the file was there, Artifactory now receives a checksum which is incorrect and correctly refuses the file with the error code 409.
THE SOLUTION (is simple):
Make 100% sure the files are definitely there before you start the deploy job (add a pause or proper logic).
There is a good possibility that the space on your remote repo is full. Verify that before going all technical and wasting time. Wasted 2-3 hrs thinking its a logical problem.
In my case the root cause for that very error was dependency version property that was not in the root pom.
The solution was moving the property to root pom where the version for the dependency was required.
So, missing version property of a dependency.
Very misleading error message indeed.
The world snapshot was written in lower case inside the pom.xml file. It must be written in upper case.
Ali

Resources