[ERROR] Failed to execute goal org.apache.maven.plugins:maven-deploy-plugin:2.7:deploy (default-deploy) on project maven-web-application: Failed to deploy artifacts: Could not transfer artifact com.mt:maven-web-application:war:2.0.7-20230110.202313-1 from/to nexus (http://172.31.7.102:8081/repository/maven-snapshots/): authentication failed for http://172.31.7.102:8081/repository/maven-snapshots/com/mt/maven-web-application/2.0.7-SNAPSHOT/maven-web-application-2.0.7-20230110.202313-1.war, status: 401 Unauthorized
I have double-checked my distribution management on my Pom file and settings.xml on both jenkins and maven and everything is 100% fine. It builds successfully on my local server but won't build on my jenkins pipeline. I have been on this issue for the last 4 days. I need help
I have double-checked my distribution management on my Pom file and settings.xml on both jenkins and maven and everything is 100% fine. It builds successfully on my local server but won't build on my jenkins pipeline. I have been on this issue for the last 4 days. please, I need help
I have a maven build for building an eclipse plugin which gets hung sporadically during the execution of
--- tycho-p2-repository-plugin:1.1.0:assemble-repository (default-assemble-repository) # com.sample.product ---
Otherwise the build will get failed saying the following error.
[ERROR] Failed to execute goal org.eclipse.tycho:tycho-p2-repository-plugin:1.1.0:assemble-repository (default-assemble-repository) on project p2:Could not assemble p2 repository: Mirroring failed: No repository found at file:/C:/Users/obuli/.m2/repository/.
I am using the following maven goals and options
clean deploy -Dtycho.localArtifacts=ignore
I have searched for this issue and landed on this Bug , It says there was a bug in tycho 0.26.0 But I am currently using Tycho version 1.1.0
Since the issue is very sporadic I could not able to identify the root cause. Please let me what I am missing here.
I intermittently had this problem as well. After running mvn clean and mvn deploy separately once, mvn clean deploy started working as well.
Now I don't seem to be able to recreate the original issue, even using git clean -xfd and deleting all snapshots from the local and remote repository.
I can only guess that there were some leftover files from earlier builds which were not cleaned by mvn clean deploy but by mvn clean, and these leftover files must have broken the build.
I use Jenkins to build a Maven project.
I have the Jenkins Credentials Plugin and the Jenkins Artifactory Plugin.
I have added my Artifactory credentials in the Credentials config.
I have configured the Artifactory plugin to use the Credentials and have set up the server URL. Test Connection works and reports back that it has found the server.
My project's POM specifies the correct Artifactory paths for the repository and the snapshotsRepository in the distributionManagement section.
My Jenkins project build is configured to do a mvn deploy.
In my local build, from my development machine, I can deploy to the Artifactory server (I have configured the credentials in my settings.xml.
However, in my Jenkins job, I want to use the Artifactory plugin and the Credentials int he Credentials plugin. When I build, I get the following
[DEBUG] Using connector WagonRepositoryConnector with priority 0 for http://xxxxx/artifactory/libs-release-local
Uploading: http://xxxxx/artifactory/libs-release-local/xxx/3.01/xxx-3.01.war
Uploading: http://xxxxx/artifactory/libs-release-local/xxx/3.01/xxx-3.01.pom
Notifying upstream projects of job completion
Join notifier requires a CauseAction
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
and the following stack trace
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-deploy-plugin:2.7:deploy (default-deploy) on project querynator:
Failed to deploy artifacts: Could not transfer artifact xxx:war:3.01 from/to dwCentral (http://xxxxx/artifactory/libs-release-local):
Failed to transfer file: http://xxxxx/artifactory/libs-release-local/xxx/3.01/xxx-3.01.war.
Return code is: 401, ReasonPhrase: .
This indicates to me the issue is with credentials, particularly since I can deploy from my dev box (using credentials in settings.xml), but not from Jenkins.
I have tried deploying a new version. I have tried deploying snapshots. This is not a version issue.
How can I I resolve this? How can I troubleshoot this further?
When using the Artifactory plugin in Jenkins, you should not use mvn deploy in the main build task. That uses the Maven Deploy Plugin, and hence will try to use credentials stored in the settings.xml file.
Instead, use mvn install as the main build task, and set up a new post-build task to Deploy Artifact to Repository.
This allows you to define the server, repository locations, and credentials to use.
Assuming you have already configured the credentials properly. If you have already deployed version lets say x.y.z to the artifactory once. Executing the command
mvn deploy
again for the same version would also result in the
Return code is: 401, ReasonPhrase: Unauthorized.
You can try updating the version to x.y.a which has never been deployed, the job should just run fine.
More from the documentation at Maven Lifecycle Basics
deploy - done in the build environment, copies the final package to
the remote repository for sharing with other developers and projects.
and assuming that you understand What exactly is a Maven Snapshot and why do we need it? and agree upon the fact that once a project is shared across things shouldn't be changing on the fly for consumers, the deploy phase is not permitted for the same version more than once.
I have a problem with jenkins version 1.500. i am trying to build a project with a dependency to another project of mine.
The error is:
[ERROR] Failed to execute goal on project projectname: Could not resolve dependencies for project projectname:jar:1.0.0: Failure to find reference-project:jar:1.0.0 in http://repo.maven.apache.org/maven2 was cached in the local repository, resolution will not be reattempted until the update interval of central has elapsed or updates are forced -> [Help 1]
If I build this project via console and Maven, the whole projects build succeed.
I checked the dependency jar file in the repository, it is there at the right place.
Does Maven have a own repository or did I miss something?
But under the Jenkins system settings, I chose "Default(~/.m2/repository)" and I did not check the checkbox "use own repository" at the project settings. Any ideas?
UPDATE
I created a extra job for the dependency in jenkins and called the Maven goal install and then everything works fine. Before this step I installed the dependency via Console and mvn install.
Why is there a difference? (i tried the given solution with delete and reinstall, but this did not help)
Simple solution delete the folder from the ~/.m2/repository which represents the artifact you've written about. ~/.m2/repository/${groupId}/... and rebuild. That happens sometimes if you have some problems during download of the artifact etc.
I too have similar problem and tried deleting the folder in ~/.m2/repository/
still its now downloading dependencies from remote repository location to local
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