I have a problem when I run the Issues Report Plugin on the multi-module project. I noted that the documentation indicated that the plugin is incompatible with this kind of project.
Nevertheless, I tried to run a sonar-runner dry run on one of the modules using its projectKey and projectName (retrieved from the widget Description). Unfortunately, the plugin has not retrieved metrics previously analyzed for this module. All anomalies are marked as new.
Is there a way to ensure I get the right values?
The dry run mode for SonarQube analyses on multi-module projects suffers from limitations, which are all fixed in the upcoming 3.6.1 version of SonarQube.
See the following ticket: https://jira.codehaus.org/browse/SONAR-4265
And just to be clear: the Issues Report Plugin does not export measures of metrics, it only exports issues.
Related
We had recently implemented SonarQube in our team and we have a dashboard configured
We've been able to see some of the details but the line coverage and code coverage is 0 always
Can you advise what we're missing ? I've checked the configuration and all of it seems to be in place
Assuming the latest SonarQube version, note that, as mentioned in this thread
Version 5.12 of our SonarJava analyzer deprecated use JaCoCo’s binary format (.exec files) to import coverage.
As a replacement, we developed the sonar-jacoco plugin, which imports JaCoCo’s XML coverage report, and this is the preferred option now. I
That page illustrates how to include those reports for a maven or a gradle project. Again, it depends on the nature of your projects.
SonarQube does no longer show test coverage for my project which is analyzed with jacoco. It seems there was an update on SonarQube (I found new rules dates May 19). I assume it also since then that the test coverage gathered with jacoco maven plugin is no longer evaluated. I've seen older questions with a similar issue, but that was 4 years ago:
JaCoCo SonarQube incompatible version 1007
I updated my POM to the latest plugin version 0.8.4 but to no avail. Any ideas where I need to change something so this works again?
I had exactly the same problem. The problem was that they deprecated the jacoco.exec file and now you have to use the XML format.
To use the new format you only have to install the official jacoco plugin in Sonarqube and everything it's going to work again without any more changes.
We currently use the sonar-scanner utility to run sonar analysis on our maven multi-modules java project.
I wanted to move from the sonar-scanner to the sonar-maven-plugin, but the first tests shows a big discrepancy in the reported metrics.
For example the number of lines of code went from 466'000 to 154'000.
The main difference seems to be that the maven plugin does not analyse the src/test directories whereas the scanner does. Another reason could be that the maven plugin only analyses the modules which are enabled.
Do this behavior seems normal to you ?
or did I miss some configuration in the plugin or the scanner. They both should pull the config from our sonarqube server.
If this is the normal behavior then should I stay with the scanner and keep the metrics history or should I start over with the maven plugin ?
I could redo some analysis for all versions we released to have some comparisons and trends.
Thanks for your advices.
Update:
Settings the sonar.sources and sonar.inclusions like mentioned there gives some better results...
sonar-maven-plugin: extending sonar.sources in multi-module project
I want to have Sonar analysis being performed on twice on the same Maven project at the same time, but different versions.
i.e. GAV details
<groupId>com.test.exm</groupId>
<artifactId>exm001</artifactId>
<version>1.5.0-SNAPSHOT</version>
AND
<groupId>com.test.exm</groupId>
<artifactId>exm001</artifactId>
<version>1.4.0-SNAPSHOT</version>
This gives the error though...
Caused by: org.sonar.api.utils.SonarException: The project is already
being analysed. at
org.sonar.batch.scan.ProjectLock.start(ProjectLock.java:55)
Please don't ask why I have snapshot 1.4.0 and 1.5.0 at the same time.
Its a legacy build thing going on in the background.
I would have thought the semaphore lock used would include the version number, not just the artifact and groupID.
I've found this defect...
https://jira.codehaus.org/browse/SONAR-2761
I could turn off sonar for the legacy stuff, but I'd sooner see if there is a fix I could make to allow Sonar to do the analysis.
In order to achieve this, you can use the sonar.branch property on the legacy version of your project.
I am trying to write my pom.xml for a multimodal flex application. I have been using this resource as an example:
http://www.sonatype.com/books/mvnref-book/reference/flex-dev-sect-creating-with-archetype.html
I am using M2E v1.01 but I am faced with a number of 'Plugin execution not covered by lifecycle configuration" errors. As far as I can see - there are no m2E connectors available to resolve this and I have tried all the Maven advice I can find - to include:
Clean
Update dependencies
Update project configuration
The problem only occurs if the project is declared as swc or swf package. My next move to ask Eclipse to 'permanently mark goal as ignored' - which seems a little brash.
Any advice would be appreciated.
Thanks in advance.
With STS 2.8.0, we have upgraded m2eclipse to be version 1.0. However, this can cause a bit of trouble with existing projects. I wrote a blog on this a couple of months ago.
http://blog.springsource.org/2011/10/18/upgrading-maven-integration-for-springsource-tool-suite-2-8-0/
Essentially, the new architecture for m2eclipse requires that each maven plugin you use must be mapped to one Eclipse plugin to handle the plugin's execution inside of Eclipse. This obviously causes problems since not every maven plugin author has the knowledge or time to create also create and maintain an Eclipse plugin.
By marking the plugin as ignored, you are saying that the plugin should never be executed inside of Eclipse (implying that whenever you need it to be executed, you will do so from the command line). Once marked as ignored, you can then change it to execute, which means that it should always be executed whenever the associated lifecycle is performed in Eclipse. This may cause performance problems, and so only do it if you know the risks.
If all this is too much for you, then STS provides a downgrade option to revert to an older version of m2eclipse. Go to the Dashboard extensions page. Unfortunately, you will have to manually revert all changes to your .project and .classpath files (we provide an auto-upgrade mechanism, but not a downgrade mechanism...presumably everything is in version control).
Any questions or problems should be sent to the STS forums:
http://forum.springsource.org/forumdisplay.php?32-SpringSource-Tool-Suite
You can check this alpha connector "Flex Maven Integration for Flash Builder" on the eclipse marketplace: http://marketplace.eclipse.org/node/648556.