I'm using sonarqube 4.5 with sonar-maven-plugin version 2.4. When I run maven sonar:sonar, I get the following error Unable to scan non-existing project "Projectname". I previously used sonarqube 4.2 and I don't remember encountering such a problem. in my settings.xml for maven, i have the following profile
<profile>
<id>sonar</id>
<activation>
<activeByDefault>true</activeByDefault>
</activation>
<properties>
<sonar.jdbc.url>jdbc:mysql://localhost:3306/sonar?useUnicode=true&characterEncoding=utf8</sonar.jdbc.url>
<sonar.jdbc.username>username</sonar.jdbc.username>
<sonar.jdbc.password>password</sonar.jdbc.password>
<sonar.host.url>http://myserver:9000</sonar.host.url>
<sonar.login>login</sonar.login>
<sonar.password>password</sonar.password>
</properties>
</profile>
This user has the following global permissions; Execute Analysis, Execute Preview Analysis and Provision Projects. the 'Provision Projects' permission states that Ability to initialize project structure before first analysis. and i imagine that this would allow the plugin to create the project in the sonar server before analysis. for sonarqube version 4.2 i never used to encounter this problem.
so the question is, how can i make the plugin create the project in the sonar server before running the analysis?
This error occurs, if your sonar user does not have the right to create new projects in sonar cube.
I fixed this by changing the configuration value to false (from the sonar dashboard)
Setting -> Prevent automatic project creation = False
A user with admin privileges needs to login to Sonar. From Settings > Provisioning needs to add the project details which are as follows:
1) Key: This is <groupid>:<artifact id> from your pom file. if you are planning to re-use the same project from your local machine then append user name to the key.
i.e <groupid>:<artifact id>:<username>
2) Name: This is the <name> tag value from the pom file.
After this is done, then if you run :
mvn sonar:sonar -Dsonar.branch=$(whoami)
Note that the use of -Dsonar.branch=$(whoami) depends if you have provisioned with the username or not if not
mvn sonar:sonar
would suffice
Related
I'm running sonarqube with maven.
I have installed it using following way.
Using brew, I installed mysql and sonar.
When I run I get 7 critical bugs but the code coverage for 88 tests is zero
When I run it with IntelliJ's tools, I get the following results. (not zero!)
This is when I check Jacoco results directly. In $base_direc/target/jacoco/index.html
The same code when run with sonar-scanner
This is my maven configuration
My ~/.m2/settings.xml
Edit 1:
I have found this in logs.
Edit2:
I have edited ~/.m2/settings.xml
added
<properties>
<sonar.host.url>http://localhost:9000/</sonar.host.url>
</properties>
Edited /usr/local/Cellar/sonarqube/6.3.1/libexec/conf/sonar.properties
added sonar.host.url=http://localhost:9000/
Edited /usr/local/etc/sonar-scanner.properties added - sonar.host.url=http://localhost:9000/
Ran the application in all above ways and the results were same, i.e, I could see Jacoco results but not in sonar.
Is it possible that if bugs are found sonar refuses to do code coverage?!
I found the solution -
The maven plugin I have included has configuration of Jacoco's destfile and datafile as ${basedir}/target/coverage-reports/jacoco-unit.exec
but by default sonar reads at ${basedir}/target/jacoco.exec. I changed the default at http://localhost:9000/settings?category=java
Ref: Sonar Code Coverage
Couldn't find the working reference link. Here is aux link: Baeldung Sonar and jacoco
I've resolved this by using the following steps:
1.To begin, I've add configuration in our pom.xml.
<properties>
<sonar.core.codeCoveragePlugin>jacoco</sonar.core.codeCoveragePlugin>
<sonar.jacoco.reportPath>${project.basedir}/../target/jacoco.exec</sonar.jacoco.reportPath>
<sonar.language>java</sonar.language>
</properties>
2.In sonarqube properties file added the below part.
sonar.projectName=${JOB_NAME}
sonar.projectVersion=1.0.0
sonar.sources=src/main
sonar.sourceEncoding=UTF-8
sonar.language=java
sonar.tests=src/test
sonar.junit.reportsPath=target/surefire-reports
sonar.surefire.reportsPath=target/surefire-reports
sonar.jacoco.reportPath=target/jacoco.exec
sonar.binaries=target/classes
sonar.java.coveragePlugin=jacoco
sonar.verbose=true
I had same problem, I will help you to resolve that. Here 1st thing is to walk through your pom file.
<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<java.version>1.8</java.version>
<jacoco.version>0.8.5</jacoco.version>
<sonar.jacoco.reportPath>target/jacoco-ut.exec</sonar.jacoco.reportPath>
<sonar.jacoco.itReportPaths>target/jacoco-it.exec</sonar.jacoco.itReportPaths>
</properties>
In pom file, you used jacoco-ut.exec you have to use below properties on your
execute SonarQube Scanner in Jenkins
sonar.java.binaries=target/classes
sonar.junit.reportsPath=target/surefire-reports
sonar.surefire.reportsPath=target/surefire-reports
sonar.jacoco.reportPath=target/jacoco-ut.exec
Keep in your mind about jacoco.exec in pom and property name of executing SonarQube Scanner in Jenkins
For me, the issue was:
Reports are getting generated at pre-package phase. Now we updated Pull Request maven phase.
mvn -B clean test to mvn -B clean package.
Also, latest SONAR prefers XML report. You can specify path in maven pom via:
<sonar.coverage.jacoco.xmlReportPaths>target/site/jacoco/jacoco.xml</sonar.coverage.jacoco.xmlReportPaths>
and in sonar project properties file:
sonar.projectKey=my-project
sonar.projectName=my-project
sonar.language=java
sonar.java.binaries=target/classes
sonar.sources=src/main
sonar.tests=src/test
sonar.exclusions=**/beans/*,**/config/*,**/constants/*,**/dtos/**,**/entity/*,**/exceptions/*,**/insights/*,**/App.java
sonar.sourceEncoding=UTF-8
sonar.dynamicAnalysis=reuseReports
sonar.junit.reportsPath=target/surefire-reports
sonar.java.coveragePlugin=jacoco
sonar.coverage.jacoco.xmlReportPaths=target/site/jacoco/jacoco.xml
I'm trying to run sonarQube through Jenkins but I have some difficulties right now. When I build a new job, I use Maven Project and inside the configuration I have to give à pom.xml path but what does it correspond to ?
Thank you in advance
You should find in any jenkins job a post action for sonarqube analyse.
The pom.xml you mention is the pom.xml for your maven project, because sometimes you can put your parent pom.xml in a subdirectory and this is the way for helping jenkins to find it.
Instead of adding Sonar Task to each project why not just configure Sonar at Global Level configuring the settings.xml for your maven configuration, just go to $HOME/someUser/.m2/settings.xml (if you don't have it created yet) with this content:
<settings>
<pluginGroups>
<pluginGroup>org.sonarsource.scanner.maven</pluginGroup>
</pluginGroups>
<profiles>
<profile>
<id>sonar</id>
<activation>
<activeByDefault>true</activeByDefault>
</activation>
<properties>
<!-- Optional URL to server. Default value is http://localhost:9000 -->
<sonar.host.url>
http://myserver:9000
</sonar.host.url>
</properties>
</profile>
</profiles>
</settings>
After you you have done that you will be able to run sonar in all the projects this way:
mvn clean verify sonar:sonar
# In some situation you may want to run sonar:sonar goal as a dedicated step. Be sure to use install as first step for multi-module projects
mvn clean install
mvn sonar:sonar
# Specify the version of sonar-maven-plugin instead of using the latest. See also 'How to Fix Version of Maven Plugin' below.
mvn org.sonarsource.scanner.maven:sonar-maven-plugin:3.2:sonar
You may find more information in sonar official documentation:
https://docs.sonarqube.org/display/SCAN/Analyzing+with+SonarQube+Scanner+for+Maven
I've a typical multi-module maven project.
There's a Jenkins job which builds and deploys all snapshots to the internal repository.
There's another Jenkins build which checks out code, updates all pom versions, and builds & deploys versioned artifacts.
I would like to optimize the latter by deploying only the needed artifacts: that's 2 or 3 out of 100+ modules.
The build should still compile and test all modules but install/deploy only selected module artifacts to internal repo.
Question: Is there a way to do it?
In this case you could define in your aggregator/parent project (from which the main build should start) to skip the install and deploy executions via a property in order to disable them through all the modules by default. Then, in the few modules where this action should still be performed, you could override the specific property to enable them back again.
Since the whole action is targeting a CI job, I would also suggest to wrap this behavior in a maven profile as following:
In your aggregator/parent project you could define:
<profiles>
<profile>
<id>ci-job</id>
<properties>
<disable.install.deploy>true</disable.install.deploy>
<maven.install.skip>${disable.install.deploy}</maven.install.skip>
<maven.deploy.skip>${disable.install.deploy}</maven.deploy.skip>
</properties>
</profile>
</profiles>
The snippet above is defining withinb the ci-job profile a new property, disable.install.deploy, set to true by default. Its value is then passed to the maven.install.skip propert of the maven-install-plugin:
Set this to true to bypass artifact installation. Use this for artifacts that does not need to be installed in the local repository.
And to the maven.deploy.skip property of the maven-deploy-plugin:
Set this to 'true' to bypass artifact deploy
As such, running the following:
mvn clean install -Pci-job
Would effectively skip install and deploy goals executions across the build (across all modules).
That's half of the job however. In the few modules where you still want this action you could then define the following:
<profiles>
<profile>
<id>ci-job</id>
<properties>
<disable.install.deploy>false</disable.install.deploy>
</properties>
</profile>
</profiles>
That is. Keeping the same profile name it will also be activated via the same global build invocation, setting however the key property to false and as such enabling again install and deploy for the modules where this profile would be added.
Im' getting an error when deploying an artifact in my own repository in a Nexus server: "Failed to deploy artifacts: Could not transfer artifact" "Failed to transfer file http:///my_artifact. Return code is: 400"
I have Nexus running with one custom repository my_repo with the next maven local configuration:
settings.xml
<server>
<id>my_repo</id>
<username>user</username>
<password>pass</password>
</server>
...
<mirror>
<id>my_repo</id>
<name>Repo Mirror</name>
<url><my_url_to_my_repo></url>
<mirrorOf>*</mirrorOf>
</mirror>
user has permissions to create/read/write into my_repo -
pom.xml
<distributionManagement>
<repository>
<id>my_repo</id>
<name>my_repo</name>
<url><my_url_to_my_repo></url>
<layout>default</layout>
</repository>
<snapshotRepository>
<id>snapshots</id>
<name>Snapshots</name>
<url><my_url_to_my_snapshot_repo></url>
</snapshotRepository>
</distributionManagement>
and then I execute
mvn deploy
and get the error. Any idea?
A couple things I can think of:
user credentials are wrong
url to server is wrong
user does not have access to the deployment repository
user does not have access to the specific repository target
artifact is already deployed with that version if it is a release (not -SNAPSHOT version)
the repository is not suitable for deployment of the respective artifact (e.g. release repo for snapshot version, proxy repo or group instead of a hosted repository)
Check those and if you still run into trouble provide more details here.
Just to create a separate answer. The answer is actually found in a comment for the accepted answer.
Try changing the version of your artefact to end with -SNAPSHOT.
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
Deploy the same version of a release artifact more than once to a release repository
Cause of problem for me was -source.jars was getting uploaded twice (with maven-source-plugin) as mentioned as one of the cause in accepted answer. Redirecting to answer that I referred:
Maven release plugin fails : source artifacts getting deployed twice
In the rare event that you need to redeploy the SAME STABLE artifact to Nexus, it will fail by default. If you then delete the artifact from Nexus (via the web interface) for the purpose of deploying it again, the deploy will still fail, since just removing the e.g. jar or pom does not clear other files still laying around in the directory. You need to log onto the box and delete the directory in its entirety.
I had this exact problem today and the problem was that the version I was trying to release:perform was already in the Nexus repo.
In my case this was likely due to a network disconnect during an earlier invocation of release:perform. Even though I lost my connection, it appears the release succeeded.
I had the same problem today with the addition "Return code is: 400, ReasonPhrase: Bad Request." which turned out to be the "artifact is already deployed with that version if it is a release" problem from answer above enter link description here
One solution not mentioned yet is to configure Nexus to allow redeployment into a Release repository. Maybe not a best practice, because this is set for a reason, you nevertheless could go to "Access Settings" in your Nexus repositories´ "Configuration"-Tab and set the "Deployment Policy" to "Allow Redeploy".
in the parent pom application==> Version put the tag as follows: x.x.x-SNAPSHOT
example :0.0.1-SNAPSHOT
"-SNAPSHOT" : is very important
Ensure that not exists already (artifact and version) in nexus (as release). In that case return Bad Request.
For 400 error, check the repository "Deployment policy" usually its "Disable redeploy". Most of the time your library version is already there that is why you received a message "Could not PUT put 'https://yoururl/some.jar'. Received status code 400 from server: Repository does not allow updating assets: "your repository name"
So, you have a few options to resolve this.
1- allow redeploy
2- delete the version from your repository which you are trying to upload
3- change the version number
If any of the above answers worked out, You can create new artifact directly from the admin side of (NEXUS Screen shot attached below).
Login to nexus UI http://YOUR_URL:8081/nexus( username: admin
default password: admin123 )
Click repositories on the left side then click the repo, For eg: click release.
Choose artifact Upload (last tab).
Choose GAV definition as GAV Param- Then enter your groupid , artifact id and version .
Choose Jar file.
Click upload artifact.
Thats it !
Now you will be able to add the corrsponding in your project.(screenshot below)
This can also happen if you have a naming policy around version, prohibiting the version# you are trying to deploy. In my case I was trying to upload a version (to release repo) 2.0.1 but later found out that our nexus configuration doesn't allow anything other than whole number for releases.
I tried later with version 2 and deployed it successfully.
The error message definitely dosen't help:
Return code is: 400, ReasonPhrase: Repository does not allow updating assets: maven-releases-xxx. -> [Help 1]
A better message could have been version 2.0.1 violates naming policy
I was getting the same 400 response status, and the issue was resolved by adding -Dresume=false.
mvn -B release:prepare release:perform -Dresume=false
In my case, the release:prepare target was being skipped and the following message was logged in the output.
[INFO] Release preparation already completed. You can now continue with release:perform, or start again using the -Dresume=false flag
I suspect that I may have made changes in the pom.xml that required forcing the release:prepare to run again before running release:perform.
Server id should match with the repository id of maven settings.xml
What worked for me was disabling the ReleaseProfile that comes with the release plugin and skipping the deployment in the deploy plugin
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-release-plugin</artifactId>
<configuration>
<tagNameFormat>v#{project.version}</tagNameFormat
<autoVersionSubmodules>true</autoVersionSubmodules>
<releaseProfiles>releases</releaseProfiles>
<useReleaseProfile>false</useReleaseProfile>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-deploy-plugin</artifactId>
<configuration>
<skip>true</skip>
</configuration>
</plugin>
Use mvn help:effective-pom
Watch our for your CI doing a deploy after your release:prepare step. For us it was recent introduction of the official Bitbucket Server Integration plugin in Jenkins that was instantly firing on the push from release:prepare.
The fix was to add a step in the plugin for "Polling ignores commits with certain messages" with: ^(?s)\[maven-release-plugin\].* (from https://stackoverflow.com/a/32371336/1399659)
I would like to be able to deploy only the POM artifact (file) without the main artifact (JAR, WAR, etc), when running mvn deploy and version is a SNAPSHOT version.
Why?
We several developers working on multiple Maven projects. We have a Hudson server with a job per Maven project and version (e.g. foo-1.2, foo-1.3). Each job builds the project and deploys it to a Nexus server (upon success). Maven projects under development are marked as such by using -SNAPSHOT postfix in the version. For example: 1.2-SNAPSHOT, 1.3-SNAPSHOT.
Here's a sample scenario how a developer work is damaged due to this architecture.
Assume two Maven projects: foo-core and foo-webapp, both at version 1.2-SNAPSHOT.
Developer A is working on foo-core, made several changes and compiled it.
Developer A continues to work, but on foo-webapp.
Developer B started working and changing foo-core. It commits his work and pushes it to the SCM.
Hudson is triggered by SCM; Builds foo-core and deploys it to the snapshot repository in Nexus.
Developer A is running mvn install on foo-webapp. Maven is checking with Nexus, and finds that there is a newer version of foo-core in Nexus. It downloads it (filled with developer B changes) and than it fails compilation, since the changes made by developer A are not in the jar located in the local repository. The download overrides the file installed there by developer A.
Existing Solutions
I looked into maven-deploy-plugin, but this plugin deploys all artifacts attached to the project. If they had a way to configure which artifacts to deploy, it would have been great.
Question: Is there any way to solve this without resorting to writing my own deploy plugin, based on maven-deploy-plugin?
Basically to the -Dfile parameter, instead of the artifact, pass the pom.xml. Run the command and yay! mvn deploy won't give you any issues now. Here's a sample deploy command :
$ mvn deploy:deploy-file -DpomFile=pom.xml -Dfile=./pom.xml -DgroupId=my.group.id -DartifactId=artifact-id -DrepositoryId=bigdata-upload-snapshots -Durl=http://maven.mymaven.com/content/repositories/snapshots/
A prerequisite for this is that the repository be added in your settings.xml
[Edit]: I have supplied the parameters -DgroupId and -DartifactId of the project in the sample deploy command but they're not required (refer to Zac's comment below)
I never heard of such a possibility and also would be very astonished if that would be possible. As the pom and the resulting artifact are some kind of unit it would make no scence (to me) to deploy only parts of them.
Nevertheless you should consider to make a separate pom project which specified dependencies and plugins you might want to use on your JAR/WAR projects like this:
<groupId>foo.bar</groupId>
<artifactId>my-pom</artifactId>
<version>1.0.0</version>
<packaging>pom</packaging>
and then inherit that pom project by your JAR/WAR projects like this:
<parent>
<groupId>foo.bar</groupId>
<artifactId>my-pom</artifactId>
<version>1.0.0</version>
</parent>
This is called project inheritance. You can change and deploy your pom project independent of the "child" artifacts.
EDIT after reading motivation:
As I understand you want to prevent maven to resolve SNAPSHOT artifacts from a repository (so that local version won't be overwritten). Have you ever tried to use the mvn -nsu option (see mvn -help)?
-nsu,--no-snapshot-updates Suppress SNAPSHOT updates
I never tried it but found this reported issue. Nevertheless I would give it a try (as the issue is not commented yet).
This works for me for deploying a pom file only (e.g next to an existing jar):
(Note: you need to specify packaging also, otherwise it will be uploaded as an .xml file which is not what you want.)
mvn deploy:deploy-file \
-Dfile=pom.xml \
-Dpackaging=pom \
-DgroupId=com.mycompany.package \
-DartifactId=my-artifact \
-Dversion=2.0.1 \
-DrepositoryId=serverIdFromSettingsXMLForCredentials \
-Durl=http://repositoryserver/myrepo/
Not exactly the answer these folks were asking for. My situation was I wanted to deploy only the parent pom. I'm using the spring-boot-thin-layout in a child module. This requires the parent module be deployed into artifactory. I added the following into my project. It enables skipping of install and/or deploy phase.
In my parent pom:
<properties>
<disable.install>true</disable.install>
<disable.deploy>true</disable.deploy>
<enable.deployAtEnd>true</enable.deployAtEnd>
</properties>
<profiles>
<profile>
<id>deploy-parent</id>
<activation>
<activeByDefault>true</activeByDefault>
</activation>
<properties>
<disable.install>true</disable.install>
<disable.deploy>true</disable.deploy>
<deployAtEnd>${enable.deployAtEnd}</deployAtEnd>
</properties>
<build>
<finalName>${project.version}</finalName>
</build>
</profile>
</profiles>
And the in my child pom(s) or any module you don't want deployed with parent:
<properties>
<maven.install.skip>${disable.install}</maven.install.skip>
<maven.deploy.skip>${disable.deploy}</maven.deploy.skip>
<deployAtEnd>${enable.deployAtEnd}</deployAtEnd>
</properties>
So effectively when I run mvn deploy on the parent pom, it will compile all the modules, not run install on anything, and then at the end deploy any module not having `