On 5/19/06, Dennis Lundberg <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
