camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bilgin Ibryam <bibr...@gmail.com>
Subject Re: [DISCUSS] - Moving towards Camel 2.11 release
Date Sat, 09 Feb 2013 16:17:21 GMT
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) <apache@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:bibryam@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: cibsen@redhat.com
> > >Web: http://fusesource.com
> > >Twitter: davsclaus
> > >Blog: http://davsclaus.com
> > >Author of Camel in Action: http://www.manning.com/ibsen
> >
> >
> >
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message