I think it will be more easy to maintain by adding some note on the java code. When we refactor the code, we don't need to find the XML to update the suppression line.
发自我的 iPhone 在 2013-1-24，上午6:13，Christian Müller <christian.muel...@gmail.com> 写道： > I prefer updating the camel-checkstyle-suppressions.xml with: > > <suppress checks="MethodLength" > files=".+[\\\/]org[\\\/]apache[\\\/]camel[\\\/]component[\\\/]redis[\\\/]CommandDispatcher\.java" > /> > > It's more clean IMO. I tested it and it works. Ready to commit. Thoughts? > > Best, > Christian > > On Wed, Jan 23, 2013 at 10:33 PM, Raul Kripalani <r...@evosent.com> wrote: > >> Isn't it less intrusive to wrap this block in //CHECKSTYLE:OFF and >> //CHECKSTYLE:ON? >> >> If it's really just the one-off case, changing the checkstyle rule for the >> entire codebase seems overkill. >> >> Regards, >> Raúl. >> On 23 Jan 2013 22:18, "Babak Vahdat" <babak.vah...@swissonline.ch> wrote: >> >>> >>> >>> Am 23.01.13 16:16 schrieb "Claus Ibsen" unter <claus.ib...@gmail.com>: >>> >>>> On Wed, Jan 23, 2013 at 1:15 PM, Babak Vahdat >>>> <babak.vah...@swissonline.ch> wrote: >>>>> Hi >>>>> >>>>> Recently Bilgin did kindly integrate his camel-redis component @ >> GitHub >>>>> to >>>>> the Camel distribution, however I think currently we don't own any >>>>> proper >>>>> documentation for it when 2.11.0 goes live: >>>>> >>>>> http://camel.apache.org/components.html >>>> >>>> Ah well spotted. Feel free to log a JIRA ticket about the missing docs. >>>> >>>> >>>>> It's also missing by the release notes as a new component: >>>>> >>>>> http://camel.apache.org/camel-2110-release.html >>>> >>>> Yeah maybe add a note to the doc JIRA about adding to release notes. >>>> And we may also need an karaf feature for it in features.xml. >>>> >>>> And osgi unit tests as well. >>> >>> Logged the following 2 tickets regarding this: >>> >>> >>> https://issues.apache.org/jira/browse/CAMEL-6001 >>> https://issues.apache.org/jira/browse/CAMEL-6002 >>> >>> >>> >>>> >>>> >>>> >>>>> >>>>> Currently it has got a CS violation where a method by >>>>> CommandDispatcher.java >>>>> is 303 lines long (maximum allowed is 200). We could either adjust the >>>>> code >>>>> or the CS rule for that. >>>> >>>> And fell free to fix any CS issues you may encounter reported by the >>>> maven tooling. >>> >>> Actually yesterday I had already fixed all of the CS violations on the >>> trunk other than this one (on purpose) as I wanted to ask others about >>> their opinion before going for it: >>> >>> http://svn.apache.org/viewvc?view=revision&revision=1437208 >>> >>> As this one is different (302 lines of code in one method instead of the >>> maximally allowed 200). I propose to relax the checkstyle rule about >> this, >>> let's say 350 lines instead of 200. Then this would already fix this last >>> violation automatically. The other option would be to split that method >>> into 2 or 3 sub-methods but looking at the logic of that method IMHO this >>> wouldn't make much sense. >>> >>> Following is the checkstyle setting we've got for this: >>> >>> <module name="MethodLength"> >>> <property name="max" value="200"/> >>> <property name="countEmpty" value="false"/> >>> </module> >>> >>> >>> Babak >>> >>>> >>>> >>>>> Babak >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> View this message in context: >> http://camel.465427.n5.nabble.com/DISCUSS-Moving-towards-Camel-2-11-relea >>>>> se-tp5725088p5726054.html >>>>> Sent from the Camel Development mailing list archive at Nabble.com. >>>> >>>> >>>> >>>> -- >>>> Claus Ibsen >>>> ----------------- >>>> Red Hat, Inc. >>>> FuseSource is now part of Red Hat >>>> Email: cib...@redhat.com >>>> Web: http://fusesource.com >>>> Twitter: davsclaus >>>> Blog: http://davsclaus.com >>>> Author of Camel in Action: http://www.manning.com/ibsen > > > > --
