camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Matèrne (jhm) <apa...@materne.de>
Subject AW: [DISCUSS] - Moving towards Camel 2.11 release
Date Wed, 06 Feb 2013 16:03:21 GMT
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
View raw message