commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dennis Lundberg <denn...@apache.org>
Subject Re: [all] Unifying maven reports?
Date Sat, 20 May 2006 10:01:20 GMT
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 <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.

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: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 
> 


-- 
Dennis Lundberg

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