The redis component documentation is done, including a blog post about it http://www.ofbizian.com/2013/02/apache-camel-meets-redis.html
Cheers Bilgin On 6 February 2013 16:03, Jan Matèrne (jhm) <apa...@materne.de> wrote: > Maybe a table (feature x option): > > Feature| | | > Option | F1 | F2 | description > -------+----+----+-------------- > Opt1 | X | - | bla bla > Opt2 | O | O | blub blub > > X - required > O - supported > - - not supported > > > Jan > > -----Ursprüngliche Nachricht----- > Von: Bilgin Ibryam [mailto:bibr...@gmail.com] > Gesendet: Mittwoch, 6. Februar 2013 15:24 > An: dev@camel.apache.org > Betreff: Re: [DISCUSS] - Moving towards Camel 2.11 release > > Guys, thanks for fixing the CS and other issues with the Redis component. > > I didn't mentioned the new component on the release or components page > because it doesn't have documentation yet. > > But I've assigned CAMEL-6001 and will be working on the documentation these > days. > I'd love to see the new component in the coming Camel release. > > PS: the reason I postponed the doc page so far is that the component > supports many commands - around 80 and each command might have different > set > of parameters, so not sure how to document it in a clever way. > The only way that comes into mind is list each command with its possible > parameters and return types, but that will be a long and slow process. Any > other ideas? > > Thanks > Bilgin > > > > 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-re > > lea > > >>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 > > > > > > > >
