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 > > > > > > > --
