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 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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ALL] Commons Parent reports
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. 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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
RE: [ALL] Commons Parent reports
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: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 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 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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
RE: [ALL] Commons Parent reports
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: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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ALL] Commons Parent reports
On 14 March 2012 16:27, Honton, Charles charles_hon...@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: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 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 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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ALL] Commons Parent reports
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? 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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ALL] Commons Parent reports
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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ALL] Commons Parent reports
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
Re: [ALL] Commons Parent reports
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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ALL] Commons Parent reports
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 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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org JUnit in Action, 2nd Ed: http://goog_1249600977http://bit.ly/ECvg0 Spring Batch in Action: http://s.apache.org/HOqhttp://bit.ly/bqpbCK Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
Re: [ALL] Commons Parent reports
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 simonetrip...@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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ALL] Commons Parent reports
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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ALL] Commons Parent reports
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 - 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 simonetrip...@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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org JUnit in Action, 2nd Ed: http://goog_1249600977http://bit.ly/ECvg0 Spring Batch in Action: http://s.apache.org/HOqhttp://bit.ly/bqpbCK Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
Re: [ALL] Commons Parent reports
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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ALL] Commons Parent reports
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 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 simonetrip...@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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org JUnit in Action, 2nd Ed: http://goog_1249600977http://bit.ly/ECvg0 Spring Batch in Action: http://s.apache.org/HOqhttp://bit.ly/bqpbCK Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ALL] Commons Parent reports
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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ALL] Commons Parent reports
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 tcu...@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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ALL] Commons Parent reports
+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 tcu...@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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- http://www.grobmeier.de https://www.timeandbill.de - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ALL] Commons Parent reports
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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ALL] Commons Parent reports
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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ALL] Commons Parent reports
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 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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ALL] Commons Parent reports
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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ALL] Commons Parent reports
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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ALL] Commons Parent reports
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 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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- http://www.grobmeier.de https://www.timeandbill.de - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ALL] Commons Parent reports
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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org smime.p7s Description: S/MIME Cryptographic Signature
Re: [ALL] Commons Parent reports
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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ALL] Commons Parent reports
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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ALL] Commons Parent reports
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 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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- http://www.grobmeier.de https://www.timeandbill.de - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ALL] Commons Parent reports
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 smime.p7s Description: S/MIME Cryptographic Signature
Re: [ALL] Commons Parent 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 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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ALL] Commons Parent reports
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 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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ALL] Commons Parent reports
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 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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ALL] Commons Parent reports
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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ALL] Commons Parent reports
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 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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ALL] Commons Parent reports
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 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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
