Henri Yandell wrote:
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.
I put it in there because it is used by nearly all commons components
today. In Maven 2 it is part of the standard reports in the
project-info-reports plugin.
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.
Do you mean that we should change our *.fml files to e.g. xdocs instead?
This report is used by 4 components.
- 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).
It's up there under "Changes since last release".
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.
Will start another thread about that...
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
