Sorry but I lost you, at that point I don't understand what meaning we want to attribute to the "checkstyle configuration can be overridden" sentence.
Do you mean that we add the suppressions file, in order to skip some violations (i.e. signature too long of the default 80 char estimated by the default rules) or committers can define their own config files? TIA, -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Mon, Feb 20, 2012 at 5:35 PM, Gary Gregory <garydgreg...@gmail.com> wrote: > On Mon, Feb 20, 2012 at 4:10 AM, Benedikt Ritter > <b...@systemoutprintln.de>wrote: > >> Am 19.02.2012 22:57, schrieb Simone Tripodi: >> >> I think it is reasonable to have Commons wide defaults but let projects >>>> override them if they want to. >>>> >>> >> I think that is, what Gary meant in the first place ;-) >> http://mail-archives.apache.**org/mod_mbox/commons-dev/**201202.mbox/%3C-* >> *662605764588844473%**40unknownmsgid%3E<http://mail-archives.apache.org/mod_mbox/commons-dev/201202.mbox/%3C-662605764588844473%40unknownmsgid%3E> > > > Yes indeed, thank you for pointing that out in the link above. I do not > like to repeat myself. > > A advantage to an overridable default is that it is quicker to get a new > project off and running without letting it go wild with yet another set of > conventions. Right now, every time I want to work with one of the 20+ > commons components (!= project), I have to create yet another IDE set of > formatter settings, it's become intolerable and sadly ironic for a project > named "Commons". > > Gary > >> >> >> To be honest, I'm really indifferent regarding what style to use. But I've >> come to the conclusion, that coding style is an important thing for some of >> you. I think the result of this discussion should be an easy way for >> everyone to switch between components, even if some components are >> developed by a few committers only (that is why I suggested to put the IDE >> configuration files on the website). >> >> Regards, >> Benedikt >> >> >> >>> that is much more than reasonable, we are on the same path now! :) >>> >>> -Simo >>> >>> http://people.apache.org/~**simonetripodi/<http://people.apache.org/%7Esimonetripodi/> >>> http://simonetripodi.**livejournal.com/<http://simonetripodi.livejournal.com/> >>> http://twitter.com/**simonetripodi <http://twitter.com/simonetripodi> >>> http://www.99soft.org/ >>> >>> >>> >>> On Sun, Feb 19, 2012 at 10:49 PM, Ralph Goers<rgo...@apache.org> wrote: >>> >>>> On Feb 19, 2012, at 12:26 PM, Simone >>>> Tripodi<simonetripodi@apache.**org<simonetrip...@apache.org>> >>>> wrote: >>>> >>>> While I agree that checkstyle has to be consistent inside each >>>>> component, so I would be +1 on having the plugin in the parent (with >>>>> PMD and Findbugs as mentioned by Gary), I am still reluctant with >>>>> adopting a general checkstyle *configuration* for all components, and >>>>> I make you a sample: commons-ognl. >>>>> >>>>> main OGNL contributors have been olamy, mcucchiara, grobmeier and >>>>> simonetripodi<http://**svnsearch.org/svnsearch/repos/** >>>>> ASF/search?path=%2Fcommons%**2Fproper%2Fognl%2Ftrunk<http://svnsearch.org/svnsearch/repos/ASF/search?path=%2Fcommons%2Fproper%2Fognl%2Ftrunk> >>>>> >. >>>>> We all (except grobmeier :P) like the mvn style (brought by >>>>> checkstyle-plugin) and we are comfortable on working with it. No one >>>>> else committed on OGNL. >>>>> So please explain me why the PMC should "force" OGNL guys on adopting >>>>> a different style in a component where just a small subset of commons >>>>> people (mainly Struts guys) is interested. >>>>> >>>>> Concluding: PMD, findbugs and checkstyle by default: +1; deciding >>>>> which style has to be applied: -1. Good practice are one thing, strict >>>>> rules are different. >>>>> >>>> >>>> I think it is reasonable to have Commons wide defaults but let projects >>>> override them if they want to. >>>> >>>> Ralph >>>> ------------------------------**------------------------------** >>>> --------- >>>> To unsubscribe, e-mail: >>>> dev-unsubscribe@commons.**apache.org<dev-unsubscr...@commons.apache.org> >>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>> >>>> >>> ------------------------------**------------------------------**--------- >>> To unsubscribe, e-mail: >>> dev-unsubscribe@commons.**apache.org<dev-unsubscr...@commons.apache.org> >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >> >> >> ------------------------------**------------------------------**--------- >> To unsubscribe, e-mail: >> dev-unsubscribe@commons.**apache.org<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_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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
