Looking for measure of Javadoc coverage in SonarQube 6.2

[Amedee Van Gasse]

Hi!

In previous versions of SonarQube I had a dashboard "Javadocs", where I had:

* History chart with time on the X axis and Javadoc coverage % on the Y axis

* Treemap with size = LoC and color = Javadoc coverage (you could drill down to class level)

* list of packages with Javadoc coverage % (you could drill down to class level)

This was very useful for my developers whenever they felt like improving the Javadoc coverage: just look for a package or a class with a lot of red or orange, and make that % chart go up.

It was kinda motivational to have this visualized, and even to set a goal: this sprint we want 2% more Javadoc coverage. And we don't cheat, it's quality documentation, not some Eclipse-autogenerated garbage, we take pride in our work!

Now, in SQ 6.2, I understand that there is more focus and custom dashboards might be distracting. I read the blog post, I understand the decision.

However, I was sort of hoping or expecting, when I go to Measures, that I could find a measure related to Javadocs.

Something like the Technical Debt Ratio, which has List, Tree, Treemap and History, would *exactly* fit my needs. Really, great job there people!

Unfortunately there is no such measure for Javadocs.

My questions:

* Is that a feature that is to be expected in future releases of SonarQube?

* For the meanwhile, in what other way could I obtain the same information?

* Is there some way that I can implement this myself and/or contribute?

Best regards,

Amedee Van Gasse

QA Engineer

iText Software

[Johan "Johnnei"]

Hello,

As far your second point: In my own projects the Javadoc information is counted for the measure 'Comments' (Measures -> Size -> Comments / Comments (%)). So for the meantime you could trace poorly documented classes down via that measure.
When you click the measure (ex: Comments Measure) you still have the List, Tree and History. If you'd pick the percentage variant you'll also get a Treemap in which you can drill down.
As a side note: This also lumps together non-javadoc comments into the same measure so it will be harder to find missing javadoc if the class overall has a decent amount of comments.

I'll leave the other two points open as I'm not in a position to give a definitive answer to those.

Kind regards,
Johan.

[Amedee Van Gasse]

Thanks Johan.

It's better than nothing. Unfortunately all our classes have a 45 line copyright header (AGPL license) so that skews the result.

I'm afraid I need to downgrade to SQ 5.x and run a second copy with SQ 6.x to see how it evolves.

[zka...@gmail.com]

We too used to use the api covered vs uncovered measure that seems to now be gone.

[Nicolas Peru]

Hi, 

While digging up old threads is not always a nice idea I realize there was no answer on that topic so : 

Those _java_ metrics have been removed from SonarJava and more importantly from the SonarQube platform. This was done, partly as part of the effort to make it less java centric. you can find more information here : https://jira.sonarsource.com/browse/SONARJAVA-1916 and there : https://jira.sonarsource.com/browse/MMF-554

Cheers, 

Le mar. 18 juil. 2017 à 00:07, <zka...@gmail.com> a écrit :

We too used to use the api covered vs uncovered measure that seems to now be gone.

--
You received this message because you are subscribed to the Google Groups "SonarQube" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sonarqube+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sonarqube/82e07385-218d-42c0-a9b1-7594ce713d04%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Nicolas Peru | SonarSource

Senior Developer

http://twitter.com/benzonico

http://sonarsource.com

[Lonzak]

After upgrading I was missing the javadoc metrics - what a bad decision to remove those. This global view was quite helpful. Why didn't you make it configurable? Those who doesn't want to see it, disable/hide it.
The reason you mentioned "to make it less java centric" is quite funny: Other languages (like C or C++) don't document or comment their API anyway *lol* :-D