You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by sebb <se...@gmail.com> on 2012/03/13 12:48:40 UTC
[ALL] Commons Parent reports
Commons Parent 24 includes the following reports:
Javadoc
Jxr
Surefire
RAT
Cobertura
Clirr
JDepend
I think the following should be added:
Changes/JIRA
The following could be added:
Findbugs
Checkstyle
Any others?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [ALL] Commons Parent reports
Posted by Gary Gregory <ga...@gmail.com>.
On Tue, Mar 13, 2012 at 8:14 AM, Simone Tripodi <si...@apache.org>wrote:
> Hi Torsten!
>
> > -1 for checkstyle
>
> With my +1 I meant that, as we discussed in another thread, the parent
> could provide a default - but overridable - configuration; I think
> that having at least one metric of code style measure in each
> component would be nice to have, so unless other preferences, the
> parent "suggests" a default config
>
+1. We need a default, Commons components can continue to override or
decide to use the default. New components coming should use the default.
Gary
>
> I would like to understand better your PoV (that would influence
> mine): which are your concerns about having the checkstyle?
>
> many thanks in advance, all the best,
> -Simo
>
> http://people.apache.org/~simonetripodi/
> http://simonetripodi.livejournal.com/
> http://twitter.com/simonetripodi
> http://www.99soft.org/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: [ALL] Commons Parent reports
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
On Tue, Mar 13, 2012 at 01:59:25PM -0400, Gary Gregory wrote:
> On Mar 13, 2012, at 12:40, Gilles Sadowski <gi...@harfang.homelinux.org> wrote:
>
> > Hi.
> >
> >>>
> >>>>> [...]
> >>>>>
> >>>>> The tools are there, but you have to tell people that they _must_ use them.
> >>>>
> >>>> Commons has already enough rules and process. As long as the releases
> >>>> are have clean code I wouldn't be too anal about the commits in
> >>>> between.
> >>>
> >>> I think that the main disagreement is here. Source code must be a clear read
> >>> for the _developers_. To put it bluntly, I don't care that the releases have
> >>> cleanly formatted code, as almost nobody is going to read those packaged
> >>> sources!
>
> And another thing: the formatting /is/ important in released sources
> because, again, this is what most users will see in their debuggers.
> Have you seen some of the JRE sources? Some files are a mess, others
> have blank lines in the middle of headers. Others look like they were
> entered by a prisoner blinded in the noon day sun after spending a
> month in the hole with bread and water ration and then given a stick
> of butter for lunch.
It sounds like I were arguing against well formatted sources. My point was
that sources must _always_ be well formatted, and not _only_ at release.
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [ALL] Commons Parent reports
Posted by sebb <se...@gmail.com>.
On 14 March 2012 16:27, Honton, Charles <Ch...@intuit.com> wrote:
> As a user of commons libraries, I look at several reports. I'll consult Javadoc first. In the case the javadoc is silent about behavior, I look at JXR.
+1, JXR has been very useful to me.
> When I am debugging my code's interaction with the commons library, I want to have the sources available to my IDE, so that I can step through the commons library.
> chas
>
> -----Original Message-----
> From: Gilles Sadowski [mailto:gilles@harfang.homelinux.org]
> Sent: Wednesday, March 14, 2012 1:51 AM
> To: dev@commons.apache.org
> Subject: Re: [ALL] Commons Parent reports
>
> On Tue, Mar 13, 2012 at 01:52:32PM -0400, Gary Gregory wrote:
>> On Mar 13, 2012, at 12:40, Gilles Sadowski <gi...@harfang.homelinux.org> wrote:
>>
>> >>>
>> >>>>> [...]
>> >>>>>
>> >>>>> The tools are there, but you have to tell people that they _must_ use them.
>> >>>>
>> >>>> Commons has already enough rules and process. As long as the releases
>> >>>> are have clean code I wouldn't be too anal about the commits in
>> >>>> between.
>> >>>
>> >>> I think that the main disagreement is here. Source code must be a clear read
>> >>> for the _developers_. To put it bluntly, I don't care that the releases have
>> >>> cleanly formatted code, as almost nobody is going to read those packaged
>> >>> sources!
>>
>> Au contraire, most users will /only/ look at the source jar because
>> that is what you use in the debugger!
>
> Here IMHO you are talking about _developers_.
> By users I meant people who include the classes JAR in their classpath.
> They will at most look at the API docs.
>
>
> Gilles
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
RE: [ALL] Commons Parent reports
Posted by "Honton, Charles" <Ch...@intuit.com>.
As a user of commons libraries, I look at several reports. I'll consult Javadoc first. In the case the javadoc is silent about behavior, I look at JXR. When I am debugging my code's interaction with the commons library, I want to have the sources available to my IDE, so that I can step through the commons library.
chas
-----Original Message-----
From: Gilles Sadowski [mailto:gilles@harfang.homelinux.org]
Sent: Wednesday, March 14, 2012 1:51 AM
To: dev@commons.apache.org
Subject: Re: [ALL] Commons Parent reports
On Tue, Mar 13, 2012 at 01:52:32PM -0400, Gary Gregory wrote:
> On Mar 13, 2012, at 12:40, Gilles Sadowski <gi...@harfang.homelinux.org> wrote:
>
> >>>
> >>>>> [...]
> >>>>>
> >>>>> The tools are there, but you have to tell people that they _must_ use them.
> >>>>
> >>>> Commons has already enough rules and process. As long as the releases
> >>>> are have clean code I wouldn't be too anal about the commits in
> >>>> between.
> >>>
> >>> I think that the main disagreement is here. Source code must be a clear read
> >>> for the _developers_. To put it bluntly, I don't care that the releases have
> >>> cleanly formatted code, as almost nobody is going to read those packaged
> >>> sources!
>
> Au contraire, most users will /only/ look at the source jar because
> that is what you use in the debugger!
Here IMHO you are talking about _developers_.
By users I meant people who include the classes JAR in their classpath.
They will at most look at the API docs.
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [ALL] Commons Parent reports
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
On Tue, Mar 13, 2012 at 01:52:32PM -0400, Gary Gregory wrote:
> On Mar 13, 2012, at 12:40, Gilles Sadowski <gi...@harfang.homelinux.org> wrote:
>
> >>>
> >>>>> [...]
> >>>>>
> >>>>> The tools are there, but you have to tell people that they _must_ use them.
> >>>>
> >>>> Commons has already enough rules and process. As long as the releases
> >>>> are have clean code I wouldn't be too anal about the commits in
> >>>> between.
> >>>
> >>> I think that the main disagreement is here. Source code must be a clear read
> >>> for the _developers_. To put it bluntly, I don't care that the releases have
> >>> cleanly formatted code, as almost nobody is going to read those packaged
> >>> sources!
>
> Au contraire, most users will /only/ look at the source jar because
> that is what you use in the debugger!
Here IMHO you are talking about _developers_.
By users I meant people who include the classes JAR in their classpath.
They will at most look at the API docs.
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [ALL] Commons Parent reports
Posted by Christian Grobmeier <gr...@gmail.com>.
On Tue, Mar 13, 2012 at 5:40 PM, Gilles Sadowski
<gi...@harfang.homelinux.org> wrote:
>> And thats what I meant with: as long as we don't have a common
>> codestyle, i does not make much sense to have a common checkstyle
>> configuration.
>
> I thought that the question was whether to generate a CheckStyle report, not
> whether the configuration should be the same...
if you add a checkstyle report without a custom config, it has the
default configuration, right? In other terms, everybody would create a
report based on this. Or am I wrong?
>> Secondly, I have not had the feeling in the past years that checkstyle
>> helped me so much (including non open source projects). And so far, my
>> code was readable.
>
> My code is also readable...
Sure, I didn't want to say otherwise :-)
> I forgot to mention earlier in this thread that a code formatter will not
> detect missing comments; I've also seen that some people using IDE let the
> software generate totally useless "place-holder" Javadoc comments. Hence
> no tool can afterwards detect that documentation is missing.
Right. I really like Torsten old blog post on JavaDoc comments:
http://vafer.org/blog/20050323095453/
If you have no good javadoc, leave it out. Sometimes you simply do not
have good javadocs.... checkdoc should not complain about my
decisions.
Cheers
>
>
> Regards,
> Gilles
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
--
http://www.grobmeier.de
https://www.timeandbill.de
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [ALL] Commons Parent reports
Posted by Gary Gregory <ga...@gmail.com>.
On Mar 13, 2012, at 12:40, Gilles Sadowski <gi...@harfang.homelinux.org> wrote:
>>>
>>>>> [...]
>>>>>
>>>>> The tools are there, but you have to tell people that they _must_ use them.
>>>>
>>>> Commons has already enough rules and process. As long as the releases
>>>> are have clean code I wouldn't be too anal about the commits in
>>>> between.
>>>
>>> I think that the main disagreement is here. Source code must be a clear read
>>> for the _developers_. To put it bluntly, I don't care that the releases have
>>> cleanly formatted code, as almost nobody is going to read those packaged
>>> sources!
Au contraire, most users will /only/ look at the source jar because
that is what you use in the debugger!
Gary
>>
>> Nobody objects using Checkstyle. Personally I object a default
>> Checkstyle config, which everybody must override. Nearly every
>> components has specifics, so everybody MUST override. What if you
>> don't want to use Checkstyle? Can you disable it?
>> What, if you use Sun conventions and Maven conventions are the
>> default? Much work! Please leave the checkstyle question to where it
>> belongs, and this is not parent pom, but the individual component.
>>
>> And thats what I meant with: as long as we don't have a common
>> codestyle, i does not make much sense to have a common checkstyle
>> configuration.
>
> I thought that the question was whether to generate a CheckStyle report, not
> whether the configuration should be the same...
>
>> Secondly, I have not had the feeling in the past years that checkstyle
>> helped me so much (including non open source projects). And so far, my
>> code was readable.
>
> My code is also readable...
>
> I forgot to mention earlier in this thread that a code formatter will not
> detect missing comments; I've also seen that some people using IDE let the
> software generate totally useless "place-holder" Javadoc comments. Hence
> no tool can afterwards detect that documentation is missing.
>
>
> Regards,
> Gilles
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [ALL] Commons Parent reports
Posted by Gary Gregory <ga...@gmail.com>.
On Mar 13, 2012, at 14:05, sebb <se...@gmail.com> wrote:
> On 13 March 2012 17:59, Gary Gregory <ga...@gmail.com> wrote:
>> On Mar 13, 2012, at 12:40, Gilles Sadowski <gi...@harfang.homelinux.org> wrote:
>>
>>> Hi.
>>>
>>>>>
>>>>>>> [...]
>>>>>>>
>>>>>>> The tools are there, but you have to tell people that they _must_ use them.
>>>>>>
>>>>>> Commons has already enough rules and process. As long as the releases
>>>>>> are have clean code I wouldn't be too anal about the commits in
>>>>>> between.
>>>>>
>>>>> I think that the main disagreement is here. Source code must be a clear read
>>>>> for the _developers_. To put it bluntly, I don't care that the releases have
>>>>> cleanly formatted code, as almost nobody is going to read those packaged
>>>>> sources!
>>
>> And another thing: the formatting /is/ important in released sources
>> because, again, this is what most users will see in their debuggers.
>> Have you seen some of the JRE sources? Some files are a mess, others
>> have blank lines in the middle of headers. Others look like they were
>> entered by a prisoner blinded in the noon day sun after spending a
>> month in the hole with bread and water ration and then given a stick
>> of butter for lunch.
>
> No, that was a 'tab' of butter (which then sometimes got stuck into the source).
Darn, I should have checkstyled my message!
Gary
>
>> Gary
>>
>>>>
>>>> Nobody objects using Checkstyle. Personally I object a default
>>>> Checkstyle config, which everybody must override. Nearly every
>>>> components has specifics, so everybody MUST override. What if you
>>>> don't want to use Checkstyle? Can you disable it?
>>>> What, if you use Sun conventions and Maven conventions are the
>>>> default? Much work! Please leave the checkstyle question to where it
>>>> belongs, and this is not parent pom, but the individual component.
>>>>
>>>> And thats what I meant with: as long as we don't have a common
>>>> codestyle, i does not make much sense to have a common checkstyle
>>>> configuration.
>>>
>>> I thought that the question was whether to generate a CheckStyle report, not
>>> whether the configuration should be the same...
>>>
>>>> Secondly, I have not had the feeling in the past years that checkstyle
>>>> helped me so much (including non open source projects). And so far, my
>>>> code was readable.
>>>
>>> My code is also readable...
>>>
>>> I forgot to mention earlier in this thread that a code formatter will not
>>> detect missing comments; I've also seen that some people using IDE let the
>>> software generate totally useless "place-holder" Javadoc comments. Hence
>>> no tool can afterwards detect that documentation is missing.
>>>
>>>
>>> Regards,
>>> Gilles
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [ALL] Commons Parent reports
Posted by sebb <se...@gmail.com>.
On 13 March 2012 17:59, Gary Gregory <ga...@gmail.com> wrote:
> On Mar 13, 2012, at 12:40, Gilles Sadowski <gi...@harfang.homelinux.org> wrote:
>
>> Hi.
>>
>>>>
>>>>>> [...]
>>>>>>
>>>>>> The tools are there, but you have to tell people that they _must_ use them.
>>>>>
>>>>> Commons has already enough rules and process. As long as the releases
>>>>> are have clean code I wouldn't be too anal about the commits in
>>>>> between.
>>>>
>>>> I think that the main disagreement is here. Source code must be a clear read
>>>> for the _developers_. To put it bluntly, I don't care that the releases have
>>>> cleanly formatted code, as almost nobody is going to read those packaged
>>>> sources!
>
> And another thing: the formatting /is/ important in released sources
> because, again, this is what most users will see in their debuggers.
> Have you seen some of the JRE sources? Some files are a mess, others
> have blank lines in the middle of headers. Others look like they were
> entered by a prisoner blinded in the noon day sun after spending a
> month in the hole with bread and water ration and then given a stick
> of butter for lunch.
No, that was a 'tab' of butter (which then sometimes got stuck into the source).
> Gary
>
>>>
>>> Nobody objects using Checkstyle. Personally I object a default
>>> Checkstyle config, which everybody must override. Nearly every
>>> components has specifics, so everybody MUST override. What if you
>>> don't want to use Checkstyle? Can you disable it?
>>> What, if you use Sun conventions and Maven conventions are the
>>> default? Much work! Please leave the checkstyle question to where it
>>> belongs, and this is not parent pom, but the individual component.
>>>
>>> And thats what I meant with: as long as we don't have a common
>>> codestyle, i does not make much sense to have a common checkstyle
>>> configuration.
>>
>> I thought that the question was whether to generate a CheckStyle report, not
>> whether the configuration should be the same...
>>
>>> Secondly, I have not had the feeling in the past years that checkstyle
>>> helped me so much (including non open source projects). And so far, my
>>> code was readable.
>>
>> My code is also readable...
>>
>> I forgot to mention earlier in this thread that a code formatter will not
>> detect missing comments; I've also seen that some people using IDE let the
>> software generate totally useless "place-holder" Javadoc comments. Hence
>> no tool can afterwards detect that documentation is missing.
>>
>>
>> Regards,
>> Gilles
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [ALL] Commons Parent reports
Posted by Gary Gregory <ga...@gmail.com>.
On Mar 13, 2012, at 12:40, Gilles Sadowski <gi...@harfang.homelinux.org> wrote:
> Hi.
>
>>>
>>>>> [...]
>>>>>
>>>>> The tools are there, but you have to tell people that they _must_ use them.
>>>>
>>>> Commons has already enough rules and process. As long as the releases
>>>> are have clean code I wouldn't be too anal about the commits in
>>>> between.
>>>
>>> I think that the main disagreement is here. Source code must be a clear read
>>> for the _developers_. To put it bluntly, I don't care that the releases have
>>> cleanly formatted code, as almost nobody is going to read those packaged
>>> sources!
And another thing: the formatting /is/ important in released sources
because, again, this is what most users will see in their debuggers.
Have you seen some of the JRE sources? Some files are a mess, others
have blank lines in the middle of headers. Others look like they were
entered by a prisoner blinded in the noon day sun after spending a
month in the hole with bread and water ration and then given a stick
of butter for lunch.
Gary
>>
>> Nobody objects using Checkstyle. Personally I object a default
>> Checkstyle config, which everybody must override. Nearly every
>> components has specifics, so everybody MUST override. What if you
>> don't want to use Checkstyle? Can you disable it?
>> What, if you use Sun conventions and Maven conventions are the
>> default? Much work! Please leave the checkstyle question to where it
>> belongs, and this is not parent pom, but the individual component.
>>
>> And thats what I meant with: as long as we don't have a common
>> codestyle, i does not make much sense to have a common checkstyle
>> configuration.
>
> I thought that the question was whether to generate a CheckStyle report, not
> whether the configuration should be the same...
>
>> Secondly, I have not had the feeling in the past years that checkstyle
>> helped me so much (including non open source projects). And so far, my
>> code was readable.
>
> My code is also readable...
>
> I forgot to mention earlier in this thread that a code formatter will not
> detect missing comments; I've also seen that some people using IDE let the
> software generate totally useless "place-holder" Javadoc comments. Hence
> no tool can afterwards detect that documentation is missing.
>
>
> Regards,
> Gilles
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [ALL] Commons Parent reports
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
Hi.
> >
> >> > [...]
> >> >
> >> > The tools are there, but you have to tell people that they _must_ use them.
> >>
> >> Commons has already enough rules and process. As long as the releases
> >> are have clean code I wouldn't be too anal about the commits in
> >> between.
> >
> > I think that the main disagreement is here. Source code must be a clear read
> > for the _developers_. To put it bluntly, I don't care that the releases have
> > cleanly formatted code, as almost nobody is going to read those packaged
> > sources!
>
> Nobody objects using Checkstyle. Personally I object a default
> Checkstyle config, which everybody must override. Nearly every
> components has specifics, so everybody MUST override. What if you
> don't want to use Checkstyle? Can you disable it?
> What, if you use Sun conventions and Maven conventions are the
> default? Much work! Please leave the checkstyle question to where it
> belongs, and this is not parent pom, but the individual component.
>
> And thats what I meant with: as long as we don't have a common
> codestyle, i does not make much sense to have a common checkstyle
> configuration.
I thought that the question was whether to generate a CheckStyle report, not
whether the configuration should be the same...
> Secondly, I have not had the feeling in the past years that checkstyle
> helped me so much (including non open source projects). And so far, my
> code was readable.
My code is also readable...
I forgot to mention earlier in this thread that a code formatter will not
detect missing comments; I've also seen that some people using IDE let the
software generate totally useless "place-holder" Javadoc comments. Hence
no tool can afterwards detect that documentation is missing.
Regards,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [ALL] Commons Parent reports
Posted by Christian Grobmeier <gr...@gmail.com>.
On Tue, Mar 13, 2012 at 5:00 PM, Gilles Sadowski
<gi...@harfang.homelinux.org> wrote:
> Hi.
>
>> > [...]
>> >
>> > The tools are there, but you have to tell people that they _must_ use them.
>>
>> Commons has already enough rules and process. As long as the releases
>> are have clean code I wouldn't be too anal about the commits in
>> between.
>
> I think that the main disagreement is here. Source code must be a clear read
> for the _developers_. To put it bluntly, I don't care that the releases have
> cleanly formatted code, as almost nobody is going to read those packaged
> sources!
Nobody objects using Checkstyle. Personally I object a default
Checkstyle config, which everybody must override. Nearly every
components has specifics, so everybody MUST override. What if you
don't want to use Checkstyle? Can you disable it?
What, if you use Sun conventions and Maven conventions are the
default? Much work! Please leave the checkstyle question to where it
belongs, and this is not parent pom, but the individual component.
And thats what I meant with: as long as we don't have a common
codestyle, i does not make much sense to have a common checkstyle
configuration.
Secondly, I have not had the feeling in the past years that checkstyle
helped me so much (including non open source projects). And so far, my
code was readable.
>
>> [...]
>
> Gilles
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
--
http://www.grobmeier.de
https://www.timeandbill.de
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [ALL] Commons Parent reports
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
Hi.
> > [...]
> >
> > The tools are there, but you have to tell people that they _must_ use them.
>
> Commons has already enough rules and process. As long as the releases
> are have clean code I wouldn't be too anal about the commits in
> between.
I think that the main disagreement is here. Source code must be a clear read
for the _developers_. To put it bluntly, I don't care that the releases have
cleanly formatted code, as almost nobody is going to read those packaged
sources!
> [...]
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [ALL] Commons Parent reports
Posted by Torsten Curdt <tc...@vafer.org>.
> I didn't think we disagreed on refusing to spend a lot of time of correcting formatting mess.
Not on that one :)
I just argue that in the days of code formatters "lot of time" has
become is quite significant.
>> Then you are probably a vocal minority here.
>
> Because I don't use an IDE or because I like clean code?
I hope that's a rhetorical question. I would think most java people use an IDE.
>> As long as there is someone that can run a code formatter before a
>> release that does not matter though.
>
> But would you be against running a formatter before committing the code.
It would be nice - but I would not want to require it.
>> Menu > "Format Source Code" > Done.
>
> ... if they don't perform the above, CheckStyle is there to remind them they
> forgot to do it.
Why not just run the formatter in the very moment you are annoyed?
>> And I say - better let's give people the tools and not just point at them.
>
> The tools are there, but you have to tell people that they _must_ use them.
Commons has already enough rules and process. As long as the releases
are have clean code I wouldn't be too anal about the commits in
between.
Summary: if you guys insist - add it ...as long as components are OK
to disable it.
I personally just don't find it useful. But I can live with the fact
that you disagree.
Now that was already 4 cents :)
cheers,
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [ALL] Commons Parent reports
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
On Tue, Mar 13, 2012 at 02:27:32PM +0100, Torsten Curdt wrote:
> > CheckStyle reports should be checked regularly. Only doing so just before a
> > release indeed leads to a lot of tedious work, because coders did not
> > respect the basic, agreed on, style.
>
> I guess we are disagreeing here.
I didn't think we disagreed on refusing to spend a lot of time of correcting
formatting mess.
>
> > I don't use an IDE, so for me, CheckStyle helps but formatter IDE plugins
> > would not. Our mileage do vary but the end-product (clean code) should not.
>
> Then you are probably a vocal minority here.
Because I don't use an IDE or because I like clean code?
> As long as there is someone that can run a code formatter before a
> release that does not matter though.
But would you be against running a formatter before committing the code.
"Modern" editors would do this as you type (like e.g. in emacs or the IDE
plugins referred to in this thread).
It's tiresome to have to read badly formatted code and it leads to spurios
commits just to straighten up the formatting.
> > As said in another post, you can always disable reports that you find
> > unhelpful.
>
> Fair enough. But projects that find it useful could also just add the report :)
> We are discussing about what should be the default here.
> That said I rather just disable it in the POM that continue with the discussion.
>
> >> The basic code style is like logging - people spent just wait too much
> >> time on this.
>
> ...because I dont' want to contribute to that time any more.
>
> > The real problem is that some coders do not do their part of the job when
> > they commit badly formatted code.
> > Those whose spend too much time are the ones who try to clean up the mess
> > afterwards.
>
> If you prefer to not use code formatter - that is. But that's your decision.
Did I say so?
I just said the opposite: I don't like that people commit badly formatted
code and...
> Menu > "Format Source Code" > Done.
... if they don't perform the above, CheckStyle is there to remind them they
forgot to do it.
> ...plus I am bet there are ways to set up code formatting for vim and
> friends - if one wanted to.
I hope that misunderstanding has been cleared now.
> > CheckStyle indeed points a finger to the right person, which IMHO helps by
> > making this person aware that he should fix it.
>
> And I say - better let's give people the tools and not just point at them.
The tools are there, but you have to tell people that they _must_ use them.
Regards,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [ALL] Commons Parent reports
Posted by Simone Tripodi <si...@apache.org>.
> Unless I'm missing something:
>
> (Using CheckStyle) != (Using the same formatting style in all projects)
+1
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [ALL] Commons Parent reports
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
On Tue, Mar 13, 2012 at 03:08:01PM +0100, Christian Grobmeier wrote:
> +1 on the mentioned plugins, except:
> -1 on checkstyle.
>
> I dont see a benefit in making checkstyle default. If somebody wants
> to use that tool, he can.
>
> What checkstyle-style would be the default? Sun conventions or maven
> style? I am for sun, Simone is for maven (i guess). Probably there is
> another component with more specific desires. I really don't want to
> discuss this issue...
>
> We are all grown up here and a small party. And we have commit
> notifications. And if a component wishes, it can use checkstyle. Just
> don't make a specific style default... it probably makes a little bit
> more sense if components would all use the same style. But we don't
> even manage to agree on a uni-build system, I really see no way to
> make it uni-styled.
Unless I'm missing something:
(Using CheckStyle) != (Using the same formatting style in all projects)
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [ALL] Commons Parent reports
Posted by Christian Grobmeier <gr...@gmail.com>.
+1 on the mentioned plugins, except:
-1 on checkstyle.
I dont see a benefit in making checkstyle default. If somebody wants
to use that tool, he can.
What checkstyle-style would be the default? Sun conventions or maven
style? I am for sun, Simone is for maven (i guess). Probably there is
another component with more specific desires. I really don't want to
discuss this issue...
We are all grown up here and a small party. And we have commit
notifications. And if a component wishes, it can use checkstyle. Just
don't make a specific style default... it probably makes a little bit
more sense if components would all use the same style. But we don't
even manage to agree on a uni-build system, I really see no way to
make it uni-styled.
On Tue, Mar 13, 2012 at 2:27 PM, Torsten Curdt <tc...@vafer.org> wrote:
>> CheckStyle reports should be checked regularly. Only doing so just before a
>> release indeed leads to a lot of tedious work, because coders did not
>> respect the basic, agreed on, style.
>
> I guess we are disagreeing here.
>
>> I don't use an IDE, so for me, CheckStyle helps but formatter IDE plugins
>> would not. Our mileage do vary but the end-product (clean code) should not.
>
> Then you are probably a vocal minority here.
> As long as there is someone that can run a code formatter before a
> release that does not matter though.
>
>> As said in another post, you can always disable reports that you find
>> unhelpful.
>
> Fair enough. But projects that find it useful could also just add the report :)
> We are discussing about what should be the default here.
> That said I rather just disable it in the POM that continue with the discussion.
>
>>> The basic code style is like logging - people spent just wait too much
>>> time on this.
>
> ...because I dont' want to contribute to that time any more.
>
>> The real problem is that some coders do not do their part of the job when
>> they commit badly formatted code.
>> Those whose spend too much time are the ones who try to clean up the mess
>> afterwards.
>
> If you prefer to not use code formatter - that is. But that's your decision.
>
> Menu > "Format Source Code" > Done.
>
> ...plus I am bet there are ways to set up code formatting for vim and
> friends - if one wanted to.
>
>> CheckStyle indeed points a finger to the right person, which IMHO helps by
>> making this person aware that he should fix it.
>
> And I say - better let's give people the tools and not just point at them.
>
> cheers,
> Torsten
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
--
http://www.grobmeier.de
https://www.timeandbill.de
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [ALL] Commons Parent reports
Posted by Simone Tripodi <si...@apache.org>.
Hi again Torsten!
I thought it would be useful having a checkstyle also becasue it is
not just a matter of code formatting rules, there are also useful
basic checks <http://checkstyle.sourceforge.net/checks.html> that help
- me, at least - on taking care of some rules I can occasionally
forget to apply.
> And I say - better let's give people the tools and not just point at them.
I agree. IIUC the proposal of putting checkstyle in the parent came
out because it is plugged in every plugin, so the purpose is more
generalize rather then point to it.
All the best!
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Tue, Mar 13, 2012 at 2:27 PM, Torsten Curdt <tc...@vafer.org> wrote:
>> CheckStyle reports should be checked regularly. Only doing so just before a
>> release indeed leads to a lot of tedious work, because coders did not
>> respect the basic, agreed on, style.
>
> I guess we are disagreeing here.
>
>> I don't use an IDE, so for me, CheckStyle helps but formatter IDE plugins
>> would not. Our mileage do vary but the end-product (clean code) should not.
>
> Then you are probably a vocal minority here.
> As long as there is someone that can run a code formatter before a
> release that does not matter though.
>
>> As said in another post, you can always disable reports that you find
>> unhelpful.
>
> Fair enough. But projects that find it useful could also just add the report :)
> We are discussing about what should be the default here.
> That said I rather just disable it in the POM that continue with the discussion.
>
>>> The basic code style is like logging - people spent just wait too much
>>> time on this.
>
> ...because I dont' want to contribute to that time any more.
>
>> The real problem is that some coders do not do their part of the job when
>> they commit badly formatted code.
>> Those whose spend too much time are the ones who try to clean up the mess
>> afterwards.
>
> If you prefer to not use code formatter - that is. But that's your decision.
>
> Menu > "Format Source Code" > Done.
>
> ...plus I am bet there are ways to set up code formatting for vim and
> friends - if one wanted to.
>
>> CheckStyle indeed points a finger to the right person, which IMHO helps by
>> making this person aware that he should fix it.
>
> And I say - better let's give people the tools and not just point at them.
>
> cheers,
> Torsten
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [ALL] Commons Parent reports
Posted by Torsten Curdt <tc...@vafer.org>.
> CheckStyle reports should be checked regularly. Only doing so just before a
> release indeed leads to a lot of tedious work, because coders did not
> respect the basic, agreed on, style.
I guess we are disagreeing here.
> I don't use an IDE, so for me, CheckStyle helps but formatter IDE plugins
> would not. Our mileage do vary but the end-product (clean code) should not.
Then you are probably a vocal minority here.
As long as there is someone that can run a code formatter before a
release that does not matter though.
> As said in another post, you can always disable reports that you find
> unhelpful.
Fair enough. But projects that find it useful could also just add the report :)
We are discussing about what should be the default here.
That said I rather just disable it in the POM that continue with the discussion.
>> The basic code style is like logging - people spent just wait too much
>> time on this.
...because I dont' want to contribute to that time any more.
> The real problem is that some coders do not do their part of the job when
> they commit badly formatted code.
> Those whose spend too much time are the ones who try to clean up the mess
> afterwards.
If you prefer to not use code formatter - that is. But that's your decision.
Menu > "Format Source Code" > Done.
...plus I am bet there are ways to set up code formatting for vim and
friends - if one wanted to.
> CheckStyle indeed points a finger to the right person, which IMHO helps by
> making this person aware that he should fix it.
And I say - better let's give people the tools and not just point at them.
cheers,
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [ALL] Commons Parent reports
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
On Tue, Mar 13, 2012 at 01:39:40PM +0100, Torsten Curdt wrote:
> I find checkstyle to be not very useful. It's more hassle than it's
> worth. It's like pointing fingers instead of helping. If you want to
> foster a certain code style provide eclipse and intellij formatter
> settings instead - that's actually helping. Especially if you run them
> before a release.
CheckStyle reports should be checked regularly. Only doing so just before a
release indeed leads to a lot of tedious work, because coders did not
respect the basic, agreed on, style.
I don't use an IDE, so for me, CheckStyle helps but formatter IDE plugins
would not. Our mileage do vary but the end-product (clean code) should not.
As said in another post, you can always disable reports that you find
unhelpful.
> The basic code style is like logging - people spent just wait too much
> time on this.
The real problem is that some coders do not do their part of the job when
they commit badly formatted code.
Those whose spend too much time are the ones who try to clean up the mess
afterwards.
CheckStyle indeed points a finger to the right person, which IMHO helps by
making this person aware that he should fix it.
> Thinks we really should care about are in the findbugs
> and PMD report. I don't see why we should make checkstyle part of the
> projects by default.
They are all useful in different ways.
Best regards,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [ALL] Commons Parent reports
Posted by Ralph Goers <ra...@dslextreme.com>.
On Mar 13, 2012, at 6:44 AM, Benedikt Ritter wrote:
> Am 13. März 2012 14:15 schrieb Gary Gregory <ga...@gmail.com>:
>> On Tue, Mar 13, 2012 at 8:39 AM, Torsten Curdt <tc...@vafer.org> wrote:
>>
>>> I find checkstyle to be not very useful. It's more hassle than it's
>>> worth. It's like pointing fingers instead of helping. If you want to
>>> foster a certain code style provide eclipse and intellij formatter
>>> settings instead - that's actually helping. Especially if you run them
>>> before a release.
>>>
>>
>> I'd /love/ to have IDE settings for formatting saved in a project. This is
>> the 21st century, all IDEs support this, if you do not use an IDE (hi
>> Gilles), then, well, you probably also like driving a stick for "control"
>> :) The only tricky part is how organize such a folder to account for
>> different IDEs and versions. For example ide/eclipse/3.7.1,
>> ide/intellij/10.5.3, and so on. Then you can move the IDE files to where
>> each IDE wants it.
>>
>
> Very big +1 Gary! It would make contributing to the various components
> so much easier (at least for people how use an IDE ;). I guess we
> should discuss this on a new thread.
Although I would also like to have the checkstyle configuration for IntelliJ as part of the project, I also like having the checkstyle report to get the overview of the whole project.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [ALL] Commons Parent reports
Posted by Benedikt Ritter <be...@googlemail.com>.
Am 13. März 2012 14:15 schrieb Gary Gregory <ga...@gmail.com>:
> On Tue, Mar 13, 2012 at 8:39 AM, Torsten Curdt <tc...@vafer.org> wrote:
>
>> I find checkstyle to be not very useful. It's more hassle than it's
>> worth. It's like pointing fingers instead of helping. If you want to
>> foster a certain code style provide eclipse and intellij formatter
>> settings instead - that's actually helping. Especially if you run them
>> before a release.
>>
>
> I'd /love/ to have IDE settings for formatting saved in a project. This is
> the 21st century, all IDEs support this, if you do not use an IDE (hi
> Gilles), then, well, you probably also like driving a stick for "control"
> :) The only tricky part is how organize such a folder to account for
> different IDEs and versions. For example ide/eclipse/3.7.1,
> ide/intellij/10.5.3, and so on. Then you can move the IDE files to where
> each IDE wants it.
>
Very big +1 Gary! It would make contributing to the various components
so much easier (at least for people how use an IDE ;). I guess we
should discuss this on a new thread.
> Gary
>
>
>> The basic code style is like logging - people spent just wait too much
>> time on this. Thinks we really should care about are in the findbugs
>> and PMD report. I don't see why we should make checkstyle part of the
>> projects by default.
>
>
>> My 2 cents,
>> Torsten
>>
>> On Tue, Mar 13, 2012 at 1:14 PM, Simone Tripodi
>> <si...@apache.org> wrote:
>> > Hi Torsten!
>> >
>> >> -1 for checkstyle
>> >
>> > With my +1 I meant that, as we discussed in another thread, the parent
>> > could provide a default - but overridable - configuration; I think
>> > that having at least one metric of code style measure in each
>> > component would be nice to have, so unless other preferences, the
>> > parent "suggests" a default config
>> >
>> > I would like to understand better your PoV (that would influence
>> > mine): which are your concerns about having the checkstyle?
>> >
>> > many thanks in advance, all the best,
>> > -Simo
>> >
>> > http://people.apache.org/~simonetripodi/
>> > http://simonetripodi.livejournal.com/
>> > http://twitter.com/simonetripodi
>> > http://www.99soft.org/
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> > For additional commands, e-mail: dev-help@commons.apache.org
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
> Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [ALL] Commons Parent reports
Posted by Gary Gregory <ga...@gmail.com>.
On Tue, Mar 13, 2012 at 8:39 AM, Torsten Curdt <tc...@vafer.org> wrote:
> I find checkstyle to be not very useful. It's more hassle than it's
> worth. It's like pointing fingers instead of helping. If you want to
> foster a certain code style provide eclipse and intellij formatter
> settings instead - that's actually helping. Especially if you run them
> before a release.
>
I'd /love/ to have IDE settings for formatting saved in a project. This is
the 21st century, all IDEs support this, if you do not use an IDE (hi
Gilles), then, well, you probably also like driving a stick for "control"
:) The only tricky part is how organize such a folder to account for
different IDEs and versions. For example ide/eclipse/3.7.1,
ide/intellij/10.5.3, and so on. Then you can move the IDE files to where
each IDE wants it.
Gary
> The basic code style is like logging - people spent just wait too much
> time on this. Thinks we really should care about are in the findbugs
> and PMD report. I don't see why we should make checkstyle part of the
> projects by default.
> My 2 cents,
> Torsten
>
> On Tue, Mar 13, 2012 at 1:14 PM, Simone Tripodi
> <si...@apache.org> wrote:
> > Hi Torsten!
> >
> >> -1 for checkstyle
> >
> > With my +1 I meant that, as we discussed in another thread, the parent
> > could provide a default - but overridable - configuration; I think
> > that having at least one metric of code style measure in each
> > component would be nice to have, so unless other preferences, the
> > parent "suggests" a default config
> >
> > I would like to understand better your PoV (that would influence
> > mine): which are your concerns about having the checkstyle?
> >
> > many thanks in advance, all the best,
> > -Simo
> >
> > http://people.apache.org/~simonetripodi/
> > http://simonetripodi.livejournal.com/
> > http://twitter.com/simonetripodi
> > http://www.99soft.org/
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: [ALL] Commons Parent reports
Posted by Torsten Curdt <tc...@vafer.org>.
I find checkstyle to be not very useful. It's more hassle than it's
worth. It's like pointing fingers instead of helping. If you want to
foster a certain code style provide eclipse and intellij formatter
settings instead - that's actually helping. Especially if you run them
before a release.
The basic code style is like logging - people spent just wait too much
time on this. Thinks we really should care about are in the findbugs
and PMD report. I don't see why we should make checkstyle part of the
projects by default.
My 2 cents,
Torsten
On Tue, Mar 13, 2012 at 1:14 PM, Simone Tripodi
<si...@apache.org> wrote:
> Hi Torsten!
>
>> -1 for checkstyle
>
> With my +1 I meant that, as we discussed in another thread, the parent
> could provide a default - but overridable - configuration; I think
> that having at least one metric of code style measure in each
> component would be nice to have, so unless other preferences, the
> parent "suggests" a default config
>
> I would like to understand better your PoV (that would influence
> mine): which are your concerns about having the checkstyle?
>
> many thanks in advance, all the best,
> -Simo
>
> http://people.apache.org/~simonetripodi/
> http://simonetripodi.livejournal.com/
> http://twitter.com/simonetripodi
> http://www.99soft.org/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [ALL] Commons Parent reports
Posted by Simone Tripodi <si...@apache.org>.
Hi Torsten!
> -1 for checkstyle
With my +1 I meant that, as we discussed in another thread, the parent
could provide a default - but overridable - configuration; I think
that having at least one metric of code style measure in each
component would be nice to have, so unless other preferences, the
parent "suggests" a default config
I would like to understand better your PoV (that would influence
mine): which are your concerns about having the checkstyle?
many thanks in advance, all the best,
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [ALL] Commons Parent reports
Posted by Torsten Curdt <tc...@vafer.org>.
> The following could be added:
>
> Findbugs
> Checkstyle
+1 for findbugs
-1 for checkstyle
cheers,
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [ALL] Commons Parent reports
Posted by sebb <se...@gmail.com>.
On 13 March 2012 11:48, sebb <se...@gmail.com> wrote:
> Commons Parent 24 includes the following reports:
>
> Javadoc
> Jxr
> Surefire
> RAT
> Cobertura
> Clirr
> JDepend
>
> I think the following should be added:
>
> Changes/JIRA
Done.
> The following could be added:
>
> Findbugs
> Checkstyle
>
> Any others?
There's obviously a lot of argument about CheckStyle (and probably PMD
too) because the report can be configured to check different things,
and not everyone agrees on what to check. Let's leave that for a
separate discussion (in another thread).
The other argument is about whether to include certain reports that
are perhaps more developer-oriented.
My view is that if a report is likely to be useful to a 3rd party
developer, we should include it.
Yes, it may make the report list a bit longer, but that is a minor
issue - and maybe one day Maven will give more control over the
layout.
Commons components tend to be fairly low-level, and are generally used
by developers in building larger applications, so it seems natural for
the developer-style reports to be available. As someone already
mentioned, reports such as Cobertura and Findbugs can help show that
we take testing and code quality seriously.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [ALL] Commons Parent reports
Posted by Simone Tripodi <si...@apache.org>.
Hi!
> Commons Parent 24 includes the following reports:
>
> Javadoc
> Jxr
> Surefire
> RAT
> Cobertura
> Clirr
> JDepend
>
> I think the following should be added:
>
> Changes/JIRA
+1 the pattern is always the same
>
> The following could be added:
>
> Findbugs
> Checkstyle
+1
>
> Any others?
PMD/CPD would be fine as well, then I think it would be complete!
best,
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [ALL] Commons Parent reports
Posted by Gary Gregory <ga...@gmail.com>.
On Tue, Mar 13, 2012 at 7:48 AM, sebb <se...@gmail.com> wrote:
> Commons Parent 24 includes the following reports:
>
> Javadoc
> Jxr
> Surefire
> RAT
> Cobertura
> Clirr
> JDepend
>
> I think the following should be added:
>
> Changes/JIRA
>
+1
>
> The following could be added:
>
> Findbugs
> Checkstyle
>
+1
>
> Any others?
>
PMD/CPD
Gary
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
RE: [ALL] Commons Parent reports
Posted by "Honton, Charles" <Ch...@intuit.com>.
Why should the developer site be any different than the release site?
-----Original Message-----
From: Gilles Sadowski [mailto:gilles@harfang.homelinux.org]
Sent: Wednesday, March 14, 2012 2:18 AM
To: dev@commons.apache.org
Subject: Re: [ALL] Commons Parent reports
On Tue, Mar 13, 2012 at 06:37:21PM +0100, Emmanuel Bourg wrote:
> Le 13/03/2012 17:52, Gilles Sadowski a écrit :
>
> >What about the "Useful for the developer" category?
>
> They are useful at release time only, then they become quickly
> outdated as the code evolves after the release.
>
> If I want to help Commons Math, I'll checkout the code and build the
> reports. Then I might inspect the Findbugs report and see if there
> is something to fix. But I'll never go to the website and browse
> months old reports.
>
> The point is, these reports are valuable if they are updated
> continuously, but that's not possible to do that, because if the
> documentation is updated, the site will expose information that is
> not applicable to the latest release, but to the next one.
>
> What I'd like to see is a more user oriented site, something clear
> and simple, and a developer oriented site with all the reports you
> want, automatically updated everyday.
+1
[All my comments were about the "developer" site (by which I mean the HTML
reports generated by "mvn site") and not about the official web site.]
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [ALL] Commons Parent reports
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
On Tue, Mar 13, 2012 at 06:37:21PM +0100, Emmanuel Bourg wrote:
> Le 13/03/2012 17:52, Gilles Sadowski a écrit :
>
> >What about the "Useful for the developer" category?
>
> They are useful at release time only, then they become quickly
> outdated as the code evolves after the release.
>
> If I want to help Commons Math, I'll checkout the code and build the
> reports. Then I might inspect the Findbugs report and see if there
> is something to fix. But I'll never go to the website and browse
> months old reports.
>
> The point is, these reports are valuable if they are updated
> continuously, but that's not possible to do that, because if the
> documentation is updated, the site will expose information that is
> not applicable to the latest release, but to the next one.
>
> What I'd like to see is a more user oriented site, something clear
> and simple, and a developer oriented site with all the reports you
> want, automatically updated everyday.
+1
[All my comments were about the "developer" site (by which I mean the HTML
reports generated by "mvn site") and not about the official web site.]
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [ALL] Commons Parent reports
Posted by "Honton, Charles" <Ch...@intuit.com>.
When I'm researching competing open-source implementations, I use reports
as part of my evaluation. The ones that are important to me are:
Javadoc
Findbugs
Surefire
Failsafe
Cobertura
If I'm evaluating an upgrade, I'll look at:
Changes
Clirr
Chas Honton
>Le 13/03/2012 17:52, Gilles Sadowski a écrit :
>
> What about the "Useful for the developer" category?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [ALL] Commons Parent reports
Posted by Emmanuel Bourg <eb...@apache.org>.
Le 13/03/2012 17:52, Gilles Sadowski a écrit :
> What about the "Useful for the developer" category?
They are useful at release time only, then they become quickly outdated
as the code evolves after the release.
If I want to help Commons Math, I'll checkout the code and build the
reports. Then I might inspect the Findbugs report and see if there is
something to fix. But I'll never go to the website and browse months old
reports.
The point is, these reports are valuable if they are updated
continuously, but that's not possible to do that, because if the
documentation is updated, the site will expose information that is not
applicable to the latest release, but to the next one.
What I'd like to see is a more user oriented site, something clear and
simple, and a developer oriented site with all the reports you want,
automatically updated everyday.
Emmanuel Bourg
Re: [ALL] Commons Parent reports
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
On Tue, Mar 13, 2012 at 05:23:06PM +0100, Emmanuel Bourg wrote:
> I'd like to see less reports by default. Most of them are only
> useful for checking a release candidate by the commons devs,
> otherwise it just clutters the sites with useless information for a
> general usage.
>
> The most important reports to publish for the public are:
> - Javadoc
> - JXR
> - Clirr
> - Changes (I prefer the changes plugin, it's much more explicit than
> a list of issues in JIRA)
>
>
> The reports only visible when voting on a release candidate:
> - Cobertura
> - Surefire
> - RAT
> - Findbugs
> - Checkstyle
>
> The useless ones:
> - JDepend
>
What about the "Useful for the developer" category?
I think that we originally mentioned a way to enable/disable the running of
the report generators. E.g. one could call from the command-line:
mvn site -Dcheckstyle=off -Dfindbugs=on
The issue is to provide a top-level working config, then everyone can easily
run whatever they need.
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [ALL] Commons Parent reports
Posted by Gary Gregory <ga...@gmail.com>.
On Mar 13, 2012, at 12:23, Emmanuel Bourg <eb...@apache.org> wrote:
> I'd like to see less reports by default. Most of them are only useful for checking a release candidate by the commons devs, otherwise it just clutters the sites with useless information for a general usage.
>
> The most important reports to publish for the public are:
> - Javadoc
> - JXR
> - Clirr
> - Changes (I prefer the changes plugin, it's much more explicit than a list of issues in JIRA)
>
>
> The reports only visible when voting on a release candidate:
> - Cobertura
> - Surefire
These two are important IMO. It shows that we are not releasing
garbage, at least if the tests pass 100% with decent code coverage.
This is part of the "open" in open source IMO. Here is our component,
warts and all, use this information as a guide to help you decide if
this component meets your quality standard. Could you imagine
Microsoft releasing Office with this information? Never! That would
help competitors too much. Hey look at this over there, they don't
even test it. Or, looky here, they released knowing this test fails!
Gary
> - RAT
> - Findbugs
> - Checkstyle
>
> The useless ones:
> - JDepend
>
>
> Emmanuel Bourg
>
>
> Le 13/03/2012 12:48, sebb a écrit :
>> Commons Parent 24 includes the following reports:
>>
>> Javadoc
>> Jxr
>> Surefire
>> RAT
>> Cobertura
>> Clirr
>> JDepend
>>
>> I think the following should be added:
>>
>> Changes/JIRA
>>
>> The following could be added:
>>
>> Findbugs
>> Checkstyle
>>
>> Any others?
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [ALL] Commons Parent reports
Posted by Emmanuel Bourg <eb...@apache.org>.
I'd like to see less reports by default. Most of them are only useful
for checking a release candidate by the commons devs, otherwise it just
clutters the sites with useless information for a general usage.
The most important reports to publish for the public are:
- Javadoc
- JXR
- Clirr
- Changes (I prefer the changes plugin, it's much more explicit than a
list of issues in JIRA)
The reports only visible when voting on a release candidate:
- Cobertura
- Surefire
- RAT
- Findbugs
- Checkstyle
The useless ones:
- JDepend
Emmanuel Bourg
Le 13/03/2012 12:48, sebb a écrit :
> Commons Parent 24 includes the following reports:
>
> Javadoc
> Jxr
> Surefire
> RAT
> Cobertura
> Clirr
> JDepend
>
> I think the following should be added:
>
> Changes/JIRA
>
> The following could be added:
>
> Findbugs
> Checkstyle
>
> Any others?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>