Details
-
Type:
Improvement
-
Status:
Open
-
Priority:
Minor
-
Resolution: Unresolved
-
Affects Version/s: 2.14
-
Fix Version/s: None
-
Component/s: Maven Plugin
-
Labels:
-
Number of attachments :
Description
Currently, sonar-maven3-plugin requires the use of global/project-wide Maven properties for most of its configuration. This is less than optimal for a couple of reasons:
*This is not standard practice and thus violates the principle of least surprise. I can't think of any other plugins setup this way.
*It separates the plugin's declaration from its settings, making it harder to determine how/where the plugin is configured.
*Makes the plugin much less self-documenting, as the help:describe plugin information does not include sonar.host.url and friends.
Moreover, this setup doesn't provide any tangible benefits that I can see.
To be clear, I'm requesting a change from this:
<project>
...
<properties>
<!-- Configuration for the org.codehaus.mojo:sonar-maven3-plugin plugin;
see it's entry in this POM's <pluginManagement/> section for more information.
The sonar.* properties are documented at http://docs.codehaus.org/display/SONAR/Analyse+with+Maven
and http://docs.codehaus.org/display/SONAR/Advanced+parameters. -->
<sonar.host.url>http://somewebserver.somewhere/sonar</sonar.host.url>
<sonar.jdbc.url>jdbc:postgresql://somedbserver.somewhere/sonar</sonar.jdbc.url>
<sonar.jdbc.username>sonar</sonar.jdbc.username>
<sonar.jdbc.password>supersecretpw</sonar.jdbc.password>
<sonar.dynamicAnalysis>reuseReports</sonar.dynamicAnalysis>
<sonar.core.codeCoveragePlugin>jacoco</sonar.core.codeCoveragePlugin>
<sonar.jacoco.reportPath>${project.build.directory}/jacoco-unit.exec</sonar.jacoco.reportPath>
</properties>
...
<build>
<pluginManagement>
<plugins>
<plugin>
<!-- Sonar (http://www.sonarsource.org/) is a CI server similar and
complementary to Hudson/Jenkins, with more of a focus on tracking code quality
over time (as opposed to Jenkins' "does it pass muster right now?" angle.
Unfortunately, this plugin's configuration must be specified through the
use of project properties, so be sure to see that section of the POM for
more details on our setup. Please note that no executions are configured
for Sonar, as it should be run manually by running "mvn sonar:sonar" after
a full "mvn clean verify" run. -->
<groupId>org.codehaus.mojo</groupId>
<artifactId>sonar-maven3-plugin</artifactId>
<version>2.14</version>
</plugin>
</plugins>
</pluginManagement>
</build>
</project>
... to this:
<project>
...
...
<build>
<pluginManagement>
<plugins>
<plugin>
<!-- Sonar (http://www.sonarsource.org/) is a CI server similar and
complementary to Hudson/Jenkins, with more of a focus on tracking code quality
over time (as opposed to Jenkins' "does it pass muster right now?" angle.
Please note that no executions are configured
for Sonar, as it should be run manually by running "mvn sonar:sonar" after
a full "mvn clean verify" run. -->
<groupId>org.codehaus.mojo</groupId>
<artifactId>sonar-maven3-plugin</artifactId>
<version>2.14</version>
<configuration>
<hostUrl>http://somewebserver.somewhere/sonar</hostUrl>
<jdbcUrl>jdbc:postgresql://somedbserver.somewhere/sonar</jdbcUrl>
<jdbcUsername>sonar</jdbcUsername>
<jdbcPassword>supersecretpw</jdbcPassword>
<dynamicAnalysis>reuseReports</dynamicAnalysis>
<codeCoveragePlugin>jacoco</codeCoveragePlugin>
<jacocoReportPath>${project.build.directory}/jacoco-unit.exec</jacocoReportPath>
</configuration>
</plugin>
</plugins>
</pluginManagement>
</build>
</project>
This is a fairly minor change that would make the plugin much more approachable for those used to Maven's typical way of doing things. I confess the sonar plugin's different approach confused me for a while, making it harder for me to figure out what was going on.
Hi Karl, it would be better to initiate a thread of discussion on the dev mailing list to discuss this point. Thanks