On Tue, Mar 13, 2012 at 01:52:32PM -0400, Gary Gregory wrote:
On Mar 13, 2012, at 12:40, Gilles Sadowski gil...@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
On Tue, Mar 13, 2012 at 01:59:25PM -0400, Gary Gregory wrote:
On Mar 13, 2012, at 12:40, Gilles Sadowski gil...@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.
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
through the
commons library.
chas
-Original Message-
From: Gilles Sadowski [mailto:gil...@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
Why should the developer site be any different than the release site?
-Original Message-
From: Gilles Sadowski [mailto:gil...@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
@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 gil...@harfang.homelinux.org
wrote:
[...]
The tools are there, but you have to tell people that they _must_ use
them.
Commons
On 13 March 2012 11:48, sebb seb...@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?
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
The following could be added:
Findbugs
Checkstyle
+1 for findbugs
-1 for checkstyle
cheers,
Torsten
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.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
On Tue, Mar 13, 2012 at 8:14 AM, Simone Tripodi simonetrip...@apache.orgwrote:
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
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
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
On Tue, Mar 13, 2012 at 8:39 AM, Torsten Curdt tcu...@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 -
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
Am 13. März 2012 14:15 schrieb Gary Gregory garydgreg...@gmail.com:
On Tue, Mar 13, 2012 at 8:39 AM, Torsten Curdt tcu...@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
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
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
+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
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
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
On Mar 13, 2012, at 6:44 AM, Benedikt Ritter wrote:
Am 13. März 2012 14:15 schrieb Gary Gregory garydgreg...@gmail.com:
On Tue, Mar 13, 2012 at 8:39 AM, Torsten Curdt tcu...@vafer.org wrote:
I find checkstyle to be not very useful. It's more hassle than it's
worth. It's like pointing
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/
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
On Tue, Mar 13, 2012 at 5:00 PM, Gilles Sadowski
gil...@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
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
-
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
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
On Tue, Mar 13, 2012 at 5:40 PM, Gilles Sadowski
gil...@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
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.
On Mar 13, 2012, at 12:23, Emmanuel Bourg ebo...@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
On Mar 13, 2012, at 12:40, Gilles Sadowski gil...@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
On Mar 13, 2012, at 12:40, Gilles Sadowski gil...@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
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
On 13 March 2012 17:59, Gary Gregory garydgreg...@gmail.com wrote:
On Mar 13, 2012, at 12:40, Gilles Sadowski gil...@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
On Mar 13, 2012, at 14:05, sebb seb...@gmail.com wrote:
On 13 March 2012 17:59, Gary Gregory garydgreg...@gmail.com wrote:
On Mar 13, 2012, at 12:40, Gilles Sadowski gil...@harfang.homelinux.org
wrote:
Hi.
[...]
The tools are there, but you have to tell people that they _must_ use
36 matches
Mail list logo
