commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Henri Yandell" <flame...@gmail.com>
Subject Re: [all] Unifying maven reports?
Date Fri, 19 May 2006 23:50:37 GMT
Answering inline from the point of view of the published website.
CI-wise, I think everything should be turned on.

On 5/19/06, Dennis Lundberg <dennisl@apache.org> wrote:
> Hello
>
> I would like to start a discussion about trying to unify which Maven
> reports should be used for each commons component. The reasons I find
> for unifying the reports are these:
> - Makes it easy for our users if we are consistent - they know what to
> expect
> - Makes it easier for us to maintain our project.xml files
> - Facilitate Maven 2 migration
>
> Digging into the Maven 1 POMs for commons proper I have come up with the
> list of reports here below. Some reports that are only used in a few
> components have been omitted. I have also tried to categorize and
> describe each report, borrowing/stealing a lot from chapter 6 in the new
> book "Better Builds with Maven".
>
> + means that I think that all components should use this report
> o means that I think this report should be optional
> - means that I don't think any component should use this report
>
>
> Standard
> + license

Useless - we should just point to the official url.

> Source health
> + checkstyle (code formatting)
> + jdepend (quality metrics)
> + pmd/cpd (bugs, code duplication, coding standards)
> + tasklist (to do list)
> - findbugs (same as pmd?)
> - simian (same as cpd)

None of these are of interest to the user.

> Tests
> + cobertura (test coverage)
> + junit (test reports)
> - clover (same as cobertura)
> - jcoverage (same as cobertura)

Agreed on dumping clover,jcoverage.  JUnit is also largely useless -
unless we plan to be releasing components that have failed junit
tests.

I think Cobertura is of value as an attempt to define quality.

> Changes since last release

Part of a CI system, not the website. +1 to all reports in a continuous website.

> + changelog (SCM activity per commit)
> + clirr (binary compatibility)
> + developer-activity (SCM activity per developer)
> + file-activity (SCM activity per file)
> o changes
> - jdiff (same as clirr)

I'd keep jdiff too, it has more information in from memory.

> Reference
> + javadoc
> + jxr (cross reference)

For every released version, and as a part of a nightly built website.

> User guide
> o faq

Fold FAQ into the user guide, which should be manually written.

> - linkcheck (might be enabled during development)

Interesting one. A nightly built website needs to be testing the
quality of the user website.

I didn't notice the changes report. That's a critical maven report (or
we could generate from JIRA if we embrace that fully - ie: All commits
have a JIRA issue).

Just some thoughts, I know there's not much agreement  with my view
that we should have two sites, so throw in as much salt as you need.

Hen

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message