On Sun, Feb 19, 2012 at 9:26 PM, Simone Tripodi <simonetrip...@apache.org> wrote: > main OGNL contributors have been olamy, mcucchiara, grobmeier and > simonetripodi > <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.
haha I always forget there are actually people who LIKE this convention ;-) > 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. its maybe my fault. I tend to think of Commons as one project which should follow one convention. Actually it is many little projects which are too small to become a tlp. My thought about standard code style: contributors can get into the code more easily. But hey, it is just a minor plus here, I agree. So please read on. > 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. Ok I follow your argument and expand it because I like it. Then it would be ok for a component to use gradle instead of maven (in theory)? The pom.xml is an artwork, but it is far from being easy to understand or even easy to use. Why do we have so many discussions on jdk 5 or not? On can we break bc or not? Dont get me wrong - I am fine with what you say. Let component committers decide (even when it means i am overruled on ognl case haha). And a component committer is somebody who actually commits code to the component - not just fixing typos in the website or caring on the clirr report. But then please let us apply generics to collections, because to my knowledge most of the committers want them. Let us break backwards compatibility (with major version bumps) when component committers feel like that without huge discussions. This approach might lead us to a more agile Commons with more releases on up-to-date technologies and I gladly will commit code the maven way. Cheers Christian > > -Simo > > http://people.apache.org/~simonetripodi/ > http://simonetripodi.livejournal.com/ > http://twitter.com/simonetripodi > http://www.99soft.org/ > > > > On Sun, Feb 19, 2012 at 4:26 PM, Christian Grobmeier > <grobme...@gmail.com> wrote: >> On Sun, Feb 19, 2012 at 4:23 PM, Ralph Goers <rgo...@apache.org> wrote: >>> On Feb 19, 2012, at 6:55 AM, Simone Tripodi <simonetrip...@apache.org> >>> wrote: >>> >>>>> Unlike Commons, you have to be granted permission to commit at other >>>>> projects at the ASF and each of them have their own PMC and build their >>>>> own communities. Commons is a single community and thus it makes sense >>>>> for developers to be able to easily switch between sub projects. Having >>>>> commonality between the projects encourages that as it means you don't >>>>> have to figure out what style settings you need as you switch between >>>>> projects. >>>>> >>>> >>>> I continue seeing it an imposition that can be avoided, since not >>>> everybody commits in each component. >>>> I switched across components and I just respected the original code >>>> format (well, not always true, because I reformatted Discovery and >>>> still regret for it) - that doesn't mean that style was always the >>>> same, since each component defined its own config (and often the >>>> exception rules) >>>> >>>> If a common style has to be applied to all commons components, IMHO a >>>> VOTE should be subjected to the PMC >>> >>> I agree with that. However, there is nothing wrong with discussing it >>> first to see if a vote is even warranted. >> >> If the question is to have a common commons codestyle, so yes. I think >> public projects should follow standards. And there are sun/oracle >> coding conventions. >> >> Cheers >> Christian >> >>> >>> Ralph >>> >>> --------------------------------------------------------------------- >>> 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 >> > > --------------------------------------------------------------------- > 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
