Maven Site, Sonar or both of them ?
As we get more and more questions about possible overlaps between Sonar and Maven Site, I think it is time to explain the clear vision we have on this important subject. Let me start by answering three questions :
- What is the Maven Site made for ?
Provide a static portal to publish documentation on projects. By the way, this portal is used by many Open Source projects as their main web site (for instance Commons Collections or Cargo). - What is Sonar made for ?
Provide an enterprise OSS capable of handling, managing and reporting all data related to source code quality
- What are the possible overlaps?
All the quality reports available in the Maven Site under “Project Documentation -> Project Reports”, such as CPD Report, PMD Report, Cobertura Tests Coverage, …
Having answered those questions, it seems pretty natural to replace the quality reports in the Maven Site by a link to the Sonar project page (permalink). By doing so, you naturally take advantage of Sonar capabilities :
- No need anymore to configure each report in the pom.xml file, Sonar will handle that when launching the maven goal
- Manage the quality profiles in a central place (the Sonar web site) and provide a ready to use code quality policy shared among your enterprise to any new project
- Benefit from the historisation mechanism built in Sonar to see how your projects evolve over time.
- Benefit from all level of aggregations provided by Sonar and stop switching from one report to another to know exactly what should be done on a project, a module, a package or a class.
- Last but not least, have a consolidated view on all projects through the Sonar home page, which does not have an equivalent in Maven Site.
In a nutshell, Maven Site is based on a document production model which is not suitable to manage, combine, historize and aggregate source code quality information : that is Sonar’s job ! To avoid the overlap, simply reference the Sonarized projects in the Maven Site.
I totally agree with you.
By Christophe DENEUX on February 5, 2009 at 1:54 pm
>To avoid the overlap, simply reference the Sonarized projects in the Maven Site.
That’s a good conclusion. To do it even easier we could imagine a new goal in the maven-project-info-reports-plugin that let configure the pom.xml with something like that:
sonar
http://host/sonar/myProject
By Xavier on February 6, 2009 at 11:21 am
Sorry, XML tags did not appear above. For information, I have registered the wish here:
http://jira.codehaus.org/browse/MPIR-149
By Xavier on February 6, 2009 at 11:56 am
While your argument has merit, I see one problem with it. You’re using an external system (i.e. sonar) to define a set of rules that apply to a project, a maven project in this case, which you call quality profile. Maven’s model, on the other hand, is to collect all this kind of information in one place, the POM. There are a bunch of ways to define rules for findbugs, checkstyle, and pmd within the pom. For example, you can reference a project containing the rules, and access them as resources. This allows provisioning of the rules in a distributed environment, and it allows users to 1) not use a sonar, 2) have one Sonar, but not clog it with metrics from 15 different CI systems, or 3) have multiple Sonars. Again, manage, combine, historize and aggregate source code quality is indeed Sonar’s job, and it does quite well. I do not believe it’s Sonar’s job to define and distribute the rules associated with that quality though. This DOES indeed come in handy in small scale projects, but it’ll quickly turn into a nuisance as you’re unable to maintain one central project configuration, or the infrastructure to distribute this configuration in a larger organization.
To get to the point, what I’m missing is a way to have Sonar adhere to rules defined in the POM (as aggregated through the POM hierarchy), is this possible?
By Fred on May 5, 2009 at 5:05 pm
I concur with Fred that you want to have 1 definition of your reports and typically you put that in the parent pom of your project. So it would be really nice if Sonar was able to relate it’s configuration to such a configurable pom.
Otherwise I see a problem to maintain that configuration outside your source code. The good thing of including it in a pom is that you also use source control for it.
By Mike van Vendeloo on May 6, 2009 at 10:27 pm
Fred and Mike, you’ve touched a sensible subject which has generated lot of discussions in the Sonar development team. Here is my point of view :
- Conceptually the POM should be totally autonomous and shouldn’t depend on anything. It’s really suitable to manage the build lifecycle but has major drawbacks when doing other things like managing code quality. For instance, when you want to exclude some sources from analysis, you need to configure the checkstyle, pmd, javancss, cobertura, … plugins on each project that need exclusions to be defined. That’s a very painful job which is risky. Moreover, if you want to really manage the code quality on all your project portfolio, you need to define several quality profiles to handle different types of projects (legacy application, technical libraries, new projects, …). Sonar allows you to centralize all those quality profiles and to quickly see which one is used by a given project. Clirr plugin is another young example. You should configure this plugin in order to know which version of the artifact you want to use to check the API compatibility against. Do you really want to put this information in a pom.xml file which should remain relatively light to be readable by anyone ?
- Our idea is very clear : the pom file is perfect to define the build lifecycle and we want to keep it simple and readable. The Sonar Maven plugin decorates on-the-fly this pom file in order to add all the logic needed to do a full quality analysis. All the quality configuration is so stored in the Sonar database.
Feel free to challenge those ideas !
By Freddy Mallet on May 7, 2009 at 3:40 pm
I understand your point of view, however, I think we’ve faced slightly different problems in our work. Firstly, I do fully agree with you that poms for projects should be small and readable, this is a where a parent-relationship becomes real handy. Pom hierarchies can be rather elaborate, to define rules on different levels on your organization. But let’s put that aside for a moment, and talk about Sonar. You say you should have one central place to store your profiles, this is definitely correct, the problem is Sonar does not allow this. I use the quality profiles outside of Sonar as well (Hudson evaluates findbugs and checkstyle results as well, for example), without Sonar even in the picture (e.g. offline, or temporary try-outs). Storing my quality profiles as maven projects, I can store multiple profiles (different artifact ids, even versioned), they’re checked in to source control, maven solves the distribution issue (we use nexus). Selecting which profile to use is distilled to a simple dependency definition, as opposed to firing up a completely different system where the distribution works completely differently, you need a separate solution for storage and backup, and no version control. Don’t get me wrong, for a small-scale project, I REALLY like the fact that everything’s working out of the box, and I definitely don’t mind putting in some extra work to get the more complicated use-case to run. What would be really sweet though, would be to have the storage/submit to the sonar instance separated from the rest, I’d run the checks and everything (findbugs, checkstyle, pmd:cpd, cobertura; incidentally, these will also run in parallell, fully utilizing multi-cores and even clusters, but let me worry about that), and would just feed the results to sonar where applicable to get all the other benefits from Sonar (Dashboard, Time Machine, etc), as these are really cool, and we’d definitely like to keep them. Is this perhaps already possible? If there’s no maven goal for this, is there perhaps a web api?
By Fred on May 8, 2009 at 11:00 am
Hi guys,
I have the need to a apply one set of coding rules on one Maven subproject, and another set on another subproject.
What is the best way to do this? From what I could see Sonar allows you to define new coding rules via extension, but not to specify which Maven subprojects/projects to apply it to.
Thanks,
Jan
By Jan Naude on September 21, 2009 at 5:49 pm
Hi Jan, you can use whatever desired quality profile to analyze a given project, but inside a project you can’t use different profiles to analyze Maven modules. This ticket is open : http://jira.codehaus.org/browse/SONAR-684, feel free to vote for it.
Regards,
Freddy
By Freddy Mallet on September 21, 2009 at 9:41 pm