You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Dennis Lundberg <de...@apache.org> on 2006/05/19 20:31:50 UTC
[all] Unifying maven reports?
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
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)
Tests
+ cobertura (test coverage)
+ junit (test reports)
- clover (same as cobertura)
- jcoverage (same as cobertura)
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)
Reference
+ javadoc
+ jxr (cross reference)
User guide
o faq
- linkcheck (might be enabled during development)
With that I will duck from the flames and see what the rest of you think :)
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Unifying maven reports?
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Martin Cooper wrote:
>> - findbugs (same as pmd?)
>
> I would rather see this as + than -.
CheckStyle, PMD and findbugs have some overlap, but each one
has also unique code quality tests. There are a few more
utilities of this kind, and there's even a Java Code Meta
Checker which consolidates their outputs in a single reports,
see
http://sourceforge.net/projects/metacheck
Well, in my experience getting this configured for a software
with some external dependencies (which usually means: mixed
styles) in a way that the signal isn't completely drowned in
noise is an art in itself.
J.Pietschmann
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Unifying maven reports?
Posted by Martin Cooper <ma...@apache.org>.
On 5/19/06, Dennis Lundberg <de...@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
>
> Source health
> + checkstyle (code formatting)
Agree. But different components use different coding styles, so although we
could standardise on the use of the plugin, we can't standardise on the
actual rule configuration.
+ jdepend (quality metrics)
> + pmd/cpd (bugs, code duplication, coding standards)
> + tasklist (to do list)
> - findbugs (same as pmd?)
I would rather see this as + than -. FindBugs is an awesome tool, and is
absolutely not the same as PMD. In my experience, FindBugs does find real,
and, in some cases, serious, bugs within the code that no other tool that
I'm aware of can discover. (Don't get me wrong - I love PMD too, but these
tools do different things, and both are very valuable.)
- simian (same as cpd)
>
> Tests
> + cobertura (test coverage)
> + junit (test reports)
> - clover (same as cobertura)
> - jcoverage (same as cobertura)
>
> Changes since last release
> + changelog (SCM activity per commit)
> + clirr (binary compatibility)
> + developer-activity (SCM activity per developer)
Does anyone really care?
+ file-activity (SCM activity per file)
As with developer-activity, I'm not sure that anyone really cares, although
I could see ever-so-slightly more justificatoin for this one.
o changes
This is only useful if people actually update it. ;-)
- jdiff (same as clirr)
>
> Reference
> + javadoc
> + jxr (cross reference)
>
> User guide
> o faq
I like the FAQ plugin. I like the way it creates all the links and sections
for you. I, for one, am not interested in having to do all that myself, so I
disagree with Hen's suggestion that we just use xdocs for the FAQs.
--
Martin Cooper
- linkcheck (might be enabled during development)
>
>
> With that I will duck from the flames and see what the rest of you think
> :)
>
> --
> Dennis Lundberg
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
Re: [all] Unifying maven reports?
Posted by Dennis Lundberg <de...@apache.org>.
Stephen Colebourne wrote:
> Dennis Lundberg wrote:
>> Changes since last release
>> + clirr (binary compatibility)
>> - jdiff (same as clirr)
>
> These are not the same as I would need both to produce a release (clirr
> for compatability, jdiff for since tags).
Oh, I didn't know that.
> Neither needs to be part of the regular website though.
Not even as a reference? For people wanting to see the API changes since
the last version. On the other hand they could look for @since tags in
the JavaDocs to find the new stuff.
> Stephen
>
> ---------------------------------------------------------------------
> 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
Re: [all] Unifying maven reports?
Posted by Stephen Colebourne <sc...@btopenworld.com>.
Dennis Lundberg wrote:
> Changes since last release
> + clirr (binary compatibility)
> - jdiff (same as clirr)
These are not the same as I would need both to produce a release (clirr
for compatability, jdiff for since tags).
Neither needs to be part of the regular website though.
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Unifying maven reports?
Posted by Dennis Lundberg <de...@apache.org>.
Well it does, if the user remembers to upgrade all three plugins instead
of just one of them :)
--
Dennis Lundberg
Lukas Theussl wrote:
> Version 1.9 of the m1 changelog plugin also introduced the
> maven.changelog.date=lastRelease option, which will set the date
> automatically to the last release found in changes.xml. I was under the
> impression that this should work the same for file-/dev-activity and
> changelog reports. If not, it's a bug and should be fixed.
>
> -Lukas
>
>
> Dennis Lundberg wrote:
>> Jörg Schaible wrote:
>>
>>> Hi Dennis,
>>>
>>> basically I am in compliance with you list except:
>>>
>>>> + developer-activity (SCM activity per developer)
>>>> + file-activity (SCM activity per file)
>>>
>>>
>>> I don't see much value in them. They just report activities for the
>>> last 30
>>> days and even worse, they are not reproduceable, e.g. if you checkout
>>> from
>>> a tag and rerun the reports, they will show nothing (since nothing has
>>> changed for that tag anymore normally within the last 30 days).
>>>
>>> If there were a possibility to create the reports for a specified
>>> time range
>>> (defined start and end) it could cover the activities since the last
>>> release to the current one, but I don't know of such a functionality.
>>
>>
>> In Maven 1 the change log report has the possible to use a date range
>> (a specified number of days, the default), a specific date (e.g. the
>> date of the last release) or a tag (but that only works for CVS). This
>> does not seem to work for developer- and file activity though, but
>> should be that hard to fix.
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Unifying maven reports?
Posted by Lukas Theussl <lt...@apache.org>.
Version 1.9 of the m1 changelog plugin also introduced the
maven.changelog.date=lastRelease option, which will set the date
automatically to the last release found in changes.xml. I was under the
impression that this should work the same for file-/dev-activity and
changelog reports. If not, it's a bug and should be fixed.
-Lukas
Dennis Lundberg wrote:
> Jörg Schaible wrote:
>
>> Hi Dennis,
>>
>> basically I am in compliance with you list except:
>>
>>> + developer-activity (SCM activity per developer)
>>> + file-activity (SCM activity per file)
>>
>>
>> I don't see much value in them. They just report activities for the
>> last 30
>> days and even worse, they are not reproduceable, e.g. if you checkout
>> from
>> a tag and rerun the reports, they will show nothing (since nothing has
>> changed for that tag anymore normally within the last 30 days).
>>
>> If there were a possibility to create the reports for a specified time
>> range
>> (defined start and end) it could cover the activities since the last
>> release to the current one, but I don't know of such a functionality.
>
>
> In Maven 1 the change log report has the possible to use a date range (a
> specified number of days, the default), a specific date (e.g. the date
> of the last release) or a tag (but that only works for CVS). This does
> not seem to work for developer- and file activity though, but should be
> that hard to fix.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Unifying maven reports?
Posted by Dennis Lundberg <de...@apache.org>.
Jörg Schaible wrote:
> Hi Dennis,
>
> basically I am in compliance with you list except:
>
>> + developer-activity (SCM activity per developer)
>> + file-activity (SCM activity per file)
>
> I don't see much value in them. They just report activities for the last 30
> days and even worse, they are not reproduceable, e.g. if you checkout from
> a tag and rerun the reports, they will show nothing (since nothing has
> changed for that tag anymore normally within the last 30 days).
>
> If there were a possibility to create the reports for a specified time range
> (defined start and end) it could cover the activities since the last
> release to the current one, but I don't know of such a functionality.
In Maven 1 the change log report has the possible to use a date range (a
specified number of days, the default), a specific date (e.g. the date
of the last release) or a tag (but that only works for CVS). This does
not seem to work for developer- and file activity though, but should be
that hard to fix.
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Unifying maven reports?
Posted by Jörg Schaible <jo...@gmx.de>.
Hi Dennis,
basically I am in compliance with you list except:
> + developer-activity (SCM activity per developer)
> + file-activity (SCM activity per file)
I don't see much value in them. They just report activities for the last 30
days and even worse, they are not reproduceable, e.g. if you checkout from
a tag and rerun the reports, they will show nothing (since nothing has
changed for that tag anymore normally within the last 30 days).
If there were a possibility to create the reports for a specified time range
(defined start and end) it could cover the activities since the last
release to the current one, but I don't know of such a functionality.
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Unifying maven reports?
Posted by Dennis Lundberg <de...@apache.org>.
Sandy McArthur wrote:
> On 5/19/06, Dennis Lundberg <de...@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
Re: [all] Unifying maven reports?
Posted by Sandy McArthur <sa...@apache.org>.
On 5/19/06, Dennis Lundberg <de...@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.
> 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.
> 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.
> Reference
> + javadoc
> + jxr (cross reference)
>
> User guide
> o faq
> - linkcheck (might be enabled during development)
Sure, why not.
--
Sandy McArthur
"He who dares not offend cannot be honest."
- Thomas Paine
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Unifying maven reports?
Posted by Dennis Lundberg <de...@apache.org>.
Lukas Theussl wrote:
> Hi,
>
> Just a few comments from an outsider:
>
> - I think the simian report is far more advanced than CPD and much
> easier to read (on the other hand it's also heavier in resources)
>
> - Since you have recently switched to JIRA I'd suggest you have a look
> at the jira plugin which I find very pretty and useful
Yes, the JIRA plugin might be a replacement for the changes plugin. I
will have a look at it.
> - IMO jira does not replace tasklist. I just did a quick grep for the
> string "@todo" over the commons codebase and got some 40 returns. I
> don't think you want to put all of those into jira.
Agreed. Tasklist are for the little things that you postpone during
development. For stuff like: "Remember to refactor these lines of code
into a method" or "This is a hack - come up with a better solution".
>
> Cheers,
> Lukas
>
>
> Phil Steitz wrote:
>> On 5/19/06, Dennis Lundberg <de...@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
>>
>>
>> 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: commons-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> 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
Re: [all] Unifying maven reports?
Posted by Lukas Theussl <lt...@apache.org>.
Hi,
Just a few comments from an outsider:
- I think the simian report is far more advanced than CPD and much
easier to read (on the other hand it's also heavier in resources)
- Since you have recently switched to JIRA I'd suggest you have a look
at the jira plugin which I find very pretty and useful
- IMO jira does not replace tasklist. I just did a quick grep for the
string "@todo" over the commons codebase and got some 40 returns. I
don't think you want to put all of those into jira.
Cheers,
Lukas
Phil Steitz wrote:
> On 5/19/06, Dennis Lundberg <de...@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
>
>
> 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: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Unifying maven reports?
Posted by Phil Steitz <ph...@gmail.com>.
On 5/19/06, Dennis Lundberg <de...@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
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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Unifying maven reports?
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Sun, 2006-05-21 at 22:06 +0200, Dennis Lundberg wrote:
> Dion Gillard wrote:
<snip>
> > We're under resourced here as it is.
> >
> > Do we really have extra volunteers waiting to frack about making reports
> > consistent?
> > Does it really make it easier for our users? I haven't seen complaints
> > about
> > inconsistent maven reports lately.
> > AFAICT, maintaining the project.xml files hasn't been a big hassle.
>
> First off, I wouldn't be starting this discussion if I wasn't prepared
> to work on it.
>
> This is one of many steps that I feel are needed to get a faster, more
> reliable and more automated system for handling our component sites.
> That would in turn free the developers, who might not be interested in
> the site stuff, to do more coding or whatever they feel like
> contributing with.
sounds good to me :)
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Unifying maven reports?
Posted by Bill Barker <wb...@wilshire.com>.
"Dennis Lundberg" <de...@apache.org> wrote in message
news:4470C843.5080107@apache.org...
> Dion Gillard wrote:
>> Guys,
>>
>> this sounds like bike shed paint discussion.
>
> Well, in that case I want mine blue ;)
>
Paint mine green ;-).
>> We're under resourced here as it is.
>>
>> Do we really have extra volunteers waiting to frack about making reports
>> consistent?
>> Does it really make it easier for our users? I haven't seen complaints
>> about
>> inconsistent maven reports lately.
>> AFAICT, maintaining the project.xml files hasn't been a big hassle.
>
> First off, I wouldn't be starting this discussion if I wasn't prepared to
> work on it.
>
> This is one of many steps that I feel are needed to get a faster, more
> reliable and more automated system for handling our component sites. That
> would in turn free the developers, who might not be interested in the site
> stuff, to do more coding or whatever they feel like contributing with.
If you want to volunteer to maintain the pom for [modeler] and [daemon],
I've got no complaints (knock yourself out :). If you want to volunteer
*my* time to maintain them, then I'm totally -1 (I consider myself being
nice by not WONTFIXing the bug that [modeler] won't even build under Maven,
even if the result is the same :).
>
> --
> Dennis Lundberg
>
>> On 5/20/06, Dennis Lundberg <de...@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
>>>
>>> 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)
>>>
>>> Tests
>>> + cobertura (test coverage)
>>> + junit (test reports)
>>> - clover (same as cobertura)
>>> - jcoverage (same as cobertura)
>>>
>>> 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)
>>>
>>> Reference
>>> + javadoc
>>> + jxr (cross reference)
>>>
>>> User guide
>>> o faq
>>> - linkcheck (might be enabled during development)
>>>
>>>
>>> With that I will duck from the flames and see what the rest of you think
>>> :)
>>>
>>> --
>>> Dennis Lundberg
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>>
>>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Unifying maven reports?
Posted by Dennis Lundberg <de...@apache.org>.
Dion Gillard wrote:
> Guys,
>
> this sounds like bike shed paint discussion.
Well, in that case I want mine blue ;)
> We're under resourced here as it is.
>
> Do we really have extra volunteers waiting to frack about making reports
> consistent?
> Does it really make it easier for our users? I haven't seen complaints
> about
> inconsistent maven reports lately.
> AFAICT, maintaining the project.xml files hasn't been a big hassle.
First off, I wouldn't be starting this discussion if I wasn't prepared
to work on it.
This is one of many steps that I feel are needed to get a faster, more
reliable and more automated system for handling our component sites.
That would in turn free the developers, who might not be interested in
the site stuff, to do more coding or whatever they feel like
contributing with.
--
Dennis Lundberg
> On 5/20/06, Dennis Lundberg <de...@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
>>
>> 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)
>>
>> Tests
>> + cobertura (test coverage)
>> + junit (test reports)
>> - clover (same as cobertura)
>> - jcoverage (same as cobertura)
>>
>> 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)
>>
>> Reference
>> + javadoc
>> + jxr (cross reference)
>>
>> User guide
>> o faq
>> - linkcheck (might be enabled during development)
>>
>>
>> With that I will duck from the flames and see what the rest of you think
>> :)
>>
>> --
>> Dennis Lundberg
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Unifying maven reports?
Posted by Henri Yandell <fl...@gmail.com>.
On 5/21/06, Dion Gillard <di...@gmail.com> wrote:
> Guys,
>
> this sounds like bike shed paint discussion.
It's more of a water cooler discussion - and I think it's pretty good
community stuff.
For example, I wrote the FAQ report off (never having used it), but
given that Martin has positive things to say about it I guess I need
to go play :)
It's all a bit long term I think - moving to Maven2 should take
priority over juggling our Maven1 builds.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Unifying maven reports?
Posted by Dion Gillard <di...@gmail.com>.
Guys,
this sounds like bike shed paint discussion.
We're under resourced here as it is.
Do we really have extra volunteers waiting to frack about making reports
consistent?
Does it really make it easier for our users? I haven't seen complaints about
inconsistent maven reports lately.
AFAICT, maintaining the project.xml files hasn't been a big hassle.
On 5/20/06, Dennis Lundberg <de...@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
>
> 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)
>
> Tests
> + cobertura (test coverage)
> + junit (test reports)
> - clover (same as cobertura)
> - jcoverage (same as cobertura)
>
> 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)
>
> Reference
> + javadoc
> + jxr (cross reference)
>
> User guide
> o faq
> - linkcheck (might be enabled during development)
>
>
> With that I will duck from the flames and see what the rest of you think
> :)
>
> --
> Dennis Lundberg
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
--
http://www.multitask.com.au/people/dion/
Chuck Norris sleeps with a night light. Not because Chuck Norris is afraid
of the dark, but because the dark is afraid of Chuck Norris
Re: [all] Unifying maven reports?
Posted by Dennis Lundberg <de...@apache.org>.
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 <de...@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
Re: [all] Unifying maven reports?
Posted by Henri Yandell <fl...@gmail.com>.
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 <de...@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.
> 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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Unifying maven reports?
Posted by Henri Yandell <fl...@gmail.com>.
Antony Riley over at osjava.org (thus my 'we'). I just talked with
Torsten on IM and he feels it's easiest to stay with the mojo's.
Sounds good to me.
Hen
On 5/20/06, Brett Porter <br...@apache.org> wrote:
> Who wrote jardiff? If there's a chance the Maven plugin can be
> maintained within that project, and Torsten can still contribute to it,
> I'm all for it. Jetty does this very successfully.
>
> - Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Unifying maven reports?
Posted by Brett Porter <br...@apache.org>.
Who wrote jardiff? If there's a chance the Maven plugin can be
maintained within that project, and Torsten can still contribute to it,
I'm all for it. Jetty does this very successfully.
- Brett
Torsten Curdt wrote:
>> > Unfortunately codehaus was down when I wanted to commit. So it's still
>> > sitting in Jira ..and on my disk
>>
>> I don't know if its desirable, but I'm pretty sure we'd be happy to
>> have the plugin live with jardiff itself if you wanted that.
>
> What do you mean? Bringing it over to jakarta/commons?
> Naaa... at least for the plugin let's better stick to the maven
> conventions. That's probably easier for the users.
>
> ...if only codehaus would come back up *sigh*
>
> cheers
> --
> Torsten
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
--
Apache Maven - http://maven.apache.org/
Better Builds with Maven - http://library.mergere.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Unifying maven reports?
Posted by Torsten Curdt <tc...@apache.org>.
> > Unfortunately codehaus was down when I wanted to commit. So it's still
> > sitting in Jira ..and on my disk
>
> I don't know if its desirable, but I'm pretty sure we'd be happy to
> have the plugin live with jardiff itself if you wanted that.
What do you mean? Bringing it over to jakarta/commons?
Naaa... at least for the plugin let's better stick to the maven
conventions. That's probably easier for the users.
...if only codehaus would come back up *sigh*
cheers
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Unifying maven reports?
Posted by Henri Yandell <fl...@gmail.com>.
On 5/19/06, Torsten Curdt <tc...@apache.org> wrote:
> > > + clirr (binary compatibility)
> >
> > You might also look at Torsten's recent work on jardiff for Maven 2.
>
> Unfortunately codehaus was down when I wanted to commit. So it's still
> sitting in Jira ..and on my disk
I don't know if its desirable, but I'm pretty sure we'd be happy to
have the plugin live with jardiff itself if you wanted that.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Unifying maven reports?
Posted by Torsten Curdt <tc...@apache.org>.
> > + checkstyle (code formatting)
> > + pmd/cpd (bugs, code duplication, coding standards)
>
> Agree, and think commons should specify common settings for both (the
> pmd ones might be harder to agree on though, so might vary).
Uh ...I think checkstyle might be a hard one. And TBH I think that's
not worth the debate. People can be very passioned about this. I also
just hate it to be locked in into some of the styling rules sometimes.
I think checkstyle like it is, is the wrong approach. It would be
really cool to have the code in the scm in a certain style and then
format it on checkout and on back to the standard format on commit.
But I fear that's a pretty wild idea :)
> > + jdepend (quality metrics)
>
> Unless you really get what it means and use it, I'd leave it out.
yepp ...leave it out
> > + tasklist (to do list)
>
> You may be able to achieve this with checkstyle instead, this one is
> really just for convenience.
I prefer the tasklist one
> > + clirr (binary compatibility)
>
> You might also look at Torsten's recent work on jardiff for Maven 2.
Unfortunately codehaus was down when I wanted to commit. So it's still
sitting in Jira ..and on my disk
> > + developer-activity (SCM activity per developer)
> > + file-activity (SCM activity per file)
>
> probably optional
I like the developer-activity one because it shows you the latest
changes. Something like the changelog report but based on the scm
commits.
> > - jdiff (same as clirr)
>
> It's actually quite different, but I think it is best used on-demand to
> browse the changes rather than as a report like clirr.
Hm.. nevery really used that one when I had clirr/jardiff though.
cheers
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Unifying maven reports?
Posted by Brett Porter <br...@apache.org>.
Dennis Lundberg wrote:
> Common setting would be good, but I will not go there just yet. I feel
> the flames burning already :)
It's a good point. I thought there was an agreed standard, but there
probably isn't. Which is good, because then I can sneak in the Maven
style with lots of whitespace (I never used to like it but it won me over :)
- Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Unifying maven reports?
Posted by Dennis Lundberg <de...@apache.org>.
Brett Porter wrote:
> Dennis Lundberg wrote:
>> 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".
>
> Why would you want to do that? :D
Oh, I don't know, maybe because it is a great book. It really is very
good Brett. You guys have done an excellent job on it.
>> + checkstyle (code formatting)
>> + pmd/cpd (bugs, code duplication, coding standards)
>
> Agree, and think commons should specify common settings for both (the
> pmd ones might be harder to agree on though, so might vary).
Common setting would be good, but I will not go there just yet. I feel
the flames burning already :)
>> + jdepend (quality metrics)
>
> Unless you really get what it means and use it, I'd leave it out.
This one was put in the list because it is used by most components
today. Do we or our users know what it means?
>> + tasklist (to do list)
>
> You may be able to achieve this with checkstyle instead, this one is
> really just for convenience.
OK, I'll have a look at that then, although I do like the new taglist
plugin for Maven 2.
>> + clirr (binary compatibility)
>
> You might also look at Torsten's recent work on jardiff for Maven 2.
>
>> + developer-activity (SCM activity per developer)
>> + file-activity (SCM activity per file)
>
> probably optional
>
>> - jdiff (same as clirr)
>
> It's actually quite different, but I think it is best used on-demand to
> browse the changes rather than as a report like clirr.
>
> Cheers,
> Brett
>
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Unifying maven reports?
Posted by Brett Porter <br...@apache.org>.
Dennis Lundberg wrote:
> 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".
Why would you want to do that? :D
> + checkstyle (code formatting)
> + pmd/cpd (bugs, code duplication, coding standards)
Agree, and think commons should specify common settings for both (the
pmd ones might be harder to agree on though, so might vary).
> + jdepend (quality metrics)
Unless you really get what it means and use it, I'd leave it out.
> + tasklist (to do list)
You may be able to achieve this with checkstyle instead, this one is
really just for convenience.
> + clirr (binary compatibility)
You might also look at Torsten's recent work on jardiff for Maven 2.
> + developer-activity (SCM activity per developer)
> + file-activity (SCM activity per file)
probably optional
> - jdiff (same as clirr)
It's actually quite different, but I think it is best used on-demand to
browse the changes rather than as a report like clirr.
Cheers,
Brett
--
Apache Maven - http://maven.apache.org/
Better Builds with Maven - http://library.mergere.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org