In a Jenkins CI job, a single module of a multi-module Maven project is checked out from svn and the following Maven goals are specified:
clean verify pmd:pmd
The build fails with the error message
org.apache.maven.project.ProjectBuildingException: Some problems were
encountered while processing the POMs: [ERROR]
'dependencies.dependency.version' for org.jdom:jdom2:jar is missing. #
line 162, column 21
The missing version is only specified in the main (master) pom, which was not checked out.
To fix this I can check out the whole multi-module project, but are there other options which limit the check-out to only the required files - the master pom.xml and the module?
Additional information: the build worked well in the past, with many other dependency versions which were not specified in the module. All these artefacts were already in the local .m2 repository. Now with a new dependency this error occurs. I guess that it has something to do how Maven handles version matching when artefacts are already installed.
Jenkins offers to perform more than one check-out operation for a Maven build job. In the first one I specifiy the path to main (master) project, and set repository depth to "files". The second contains the module to-be-verified.
I am able to build the code from the dependencies as a free style jenkins job. But when I creating a pipeline and during the package stage I am getting the following error:
Error*
POM file $workspace/project/pom.xml specified with the -f/--file command line argument does not exist
How can I make pom.xml readable I am using maven here.
The versions of my system are the following:
Jenkins ver. 1.633
Ubuntu version 14.04.2 LTS
Maven version 3.0.5
I have configured the Maven settings under "Manage Jenkins"-->"Configure system".
When I create an "Invoke top-level Maven targets" step in the "Pre Steps" section everything works as expected. In the "Goals" line I can specify "-X", "clean install", etc. and maven picks this Goals up by printing for example :
[DEBUG] Reading global settings from .../settings.xml
[DEBUG] Reading user settings from .../settings.xml
[DEBUG] Using local repository at .../repository
When I set the same goals (for example -X) in the "Goals and options" input field of the "Build section" I get only the following Jenkins console output:
Parsing POMs ERROR: Failed to parse POMs
org.apache.maven.project.ProjectBuildingException: Some problems were
encountered while processing the POMs: [FATAL] Non-resolvable parent
POM: Failure to find nl.icscards:ics-build-parent:pom:1.1.8 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 and
'parent.relativePath' points at wrong local POM # line 6, column 10
at
org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:364)
at hudson.maven.MavenEmbedder.buildProjects(MavenEmbedder.java:361)
at hudson.maven.MavenEmbedder.readProjects(MavenEmbedder.java:331)
at
hudson.maven.MavenModuleSetBuild$PomParser.invoke(MavenModuleSetBuild.java:1301)
at
hudson.maven.MavenModuleSetBuild$PomParser.invoke(MavenModuleSetBuild.java:1098)
at hudson.FilePath.act(FilePath.java:991) at
hudson.FilePath.act(FilePath.java:969) at
hudson.maven.MavenModuleSetBuild$MavenModuleSetBuildExecution.parsePoms(MavenModuleSetBuild.java:960)
at
hudson.maven.MavenModuleSetBuild$MavenModuleSetBuildExecution.doRun(MavenModuleSetBuild.java:679)
at
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:537)
at hudson.model.Run.execute(Run.java:1741) at
hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:531) at
hudson.model.ResourceController.execute(ResourceController.java:98)
at hudson.model.Executor.run(Executor.java:408) Finished: FAILURE
What I expect by specifying "-X" is to get some debugging information the same way as I do when invoking "Invoke top-level Maven targets" as a pre build step like I've shown above.
Please also note that everything works as expected as well if I create a "Freestyle project" instead of a "Maven Project" and execute there a shell statement of the form
cd <job_workspace>
mvn -X clean install
Also in this case I can see the expected output.
Any suggestions of what could be wrong in my "Maven project" jenkins configuration?
Thanks in advance for any replies.
Turns out that the problem was that maven could not find the parent pom which is an external dependency to the project.
The strange thing is that a Maven Jenkins project tries to get these dependencies even before maven can print debug information like which settings file it uses on the jenkins console. Therefore it fails, but it is difficult to guess what the issue is. I thought that it couldn't pick up the right repository path or the right settings.xml file.
In my case the issue was that in the parent pom dependency in the repository I have a file
parent.pom.lastUpdated
which contains a line:
http\://<private-VPN-host>/repo/repo-central/.lastUpdated=1439803113007
From the jenkins server I don't have access to the private VPN host and therefore it fails. Removing that file or the above line solves the problem.
The dependency is than correctly picked up and the maven project builds correctly.
Recently I upgraded sonarqube from 4.0 to 4.3.3. Post upgrade when I try to run the maven build I am getting the error:
Failed to execute goal org.codehaus.mojo:sonar-maven-plugin:2.4:sonar (default-cli) on project xxx on project yyy Module "abc.def.xyz" is already part of project of other project.
The issue is we scan on multiple branches so we will have modules with the same name.
Is there a way to turn off this validation?
Assume you have multiple modules Maven project with below structure:
com.company:project
com.company:project-module1
com.company:project-module2
In your java source code, now "com.company:project" renamed to "com.company:myProject", so new java source strucutre becomes:
com.company:myProject
com.company:project-module1
com.company:project-module2
When you build new source and push analysis data to Sonar, it prompt:
[ERROR] Failed to execute goal
org.sonarsource.scanner.maven:sonar-maven-plugin:3.2:sonar
(default-cli) on project myProject: Module
"com.company:project-module1" is already part of project
"com.company:project" -> [Help 1]
This error is because the "com.company:project-module1" already executed and registered into Sonar before and now it belongs to "com.company:project" project whihc no longer exist in your source code anymore.
Solution:
In Sonar project configuration --> Update key, change the project "com.company:project" key from "com.company:project" to "com.company:myProject", rerun Maven build and push to Sonar, issue will solve.
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