commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Phil Steitz" <phil.ste...@gmail.com>
Subject Re: [all] Unifying maven reports?
Date Fri, 19 May 2006 19:29:25 GMT
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

Thanks for raising this.  We have talked about standardizing a few
times in the past with no consensus.  Planning for Maven 2 is a good
reason to reopen now.

>
> 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
>
Nice.
>
> Standard
> + license
+
>
> Source health
> + checkstyle (code formatting)
I would make this and pmd 0, with recommendation that at lease one of
them be present
> + jdepend (quality metrics)
0 -- should be optional
> + pmd/cpd (bugs, code duplication, coding standards)
0 (see above)
> + tasklist (to do list)
-  , maybe 0.  That's what Jira is for and some of us have a hard time
spelling "todo".

> - findbugs (same as pmd?)
0 (see above)
> - simian (same as cpd)
-
>
> Tests
> + cobertura (test coverage)
+
> + junit (test reports)
+
> - clover (same as cobertura)
-
> - jcoverage (same as cobertura)
-
>
> Changes since last release
All 0's because this depends on how frequently the site is refreshed.
Unless and until we get to automated site updates, these only have
value if committers are in the habit of updating the site after every
significant change.

> + changelog (SCM activity per commit)
0
> + clirr (binary compatibility)
0 - but we should publish these separately at release time as part of
the release documentation
> + developer-activity (SCM activity per developer)
0
> + file-activity (SCM activity per file)
0
> o changes
0, but verging on + -- this makes release notes much easier and makes
it easy for users / contributors to see what has been going on since
last release if maintained.
> - jdiff (same as clirr)
See comment on clirr.  Like the coding style thingies, one is
sufficient.  I personally like clirr a little better.
>
> Reference
> + javadoc
+
> + jxr (cross reference)
+
>
> User guide
> o faq
0
> - linkcheck (might be enabled during development)
- only valuable when validating releases
>
>

Phil

---------------------------------------------------------------------
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