Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Received-SPF: neutral (asf.osuosl.org: local policy)
Message-ID: <446EEC29.2000209@apache.org>
Date: Sat, 20 May 2006 12:15:05 +0200
From: Dennis Lundberg <dennisl@apache.org>
User-Agent: Thunderbird 1.5.0.2 (Windows/20060308)
MIME-Version: 1.0
To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
Subject: Re: [all] Unifying maven reports?
References: <446E0F16.2030707@apache.org>
 <6bde122b0605192310k20dacd77nd827b75d38885d7c@mail.gmail.com>
In-Reply-To: <6bde122b0605192310k20dacd77nd827b75d38885d7c@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Sandy McArthur wrote:
> On 5/19/06, Dennis Lundberg <dennisl@apache.org> wrote:
>> I would like to start a discussion about trying to unify which Maven
>> reports should be used for each commons component.
> 
>> 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)
> 
> Those reports are interesting to developers while developing code.
> Other than that, who cares? I've never chosen one lib over another
> because of the source code style or any other of those reports.

Yes, these are mainly for developers, although one could argue that 
pmd/cpd and findbugs can show some signs of quality.

>> Tests
>> + cobertura (test coverage)
>> + junit (test reports)
>> - clover (same as cobertura)
>> - jcoverage (same as cobertura)
> 
> A measure unit test coverage is nice to have. I have an increasing
> level of warm fuzzy feelings knowing you've reached the 80, 90, or 95
> unit test coverage percents. But that doesn't mean much if the tests
> verify wrong behavior or don't actually test what is trying to be
> tested. Personally I'm happy to use clover with my IDE integration.

Right, testing has do be done right. But as a tool to see where more 
testing is needed these are good to have.

>> Changes since last release
>> + 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)
> 
> A running change log and the ability to compare API changes is useful.
> Other stuff such as developer activity or file activity is less
> interesting, especially if you monitor the commits on -dev.

I all depends on how closely you follow the dev-list. For myself I only 
follow the commits closely for a select group of components. I think 
that these reports is useful during release-checking when you want to 
get an overview of what has happens in a component, since the last release.

>> Reference
>> + javadoc
>> + jxr (cross reference)
>>
>> User guide
>> o faq
>> - linkcheck (might be enabled during development)
> 
> Sure, why not.


-- 
Dennis Lundberg

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org