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 <[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 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
