camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Babak Vahdat <babak.vah...@swissonline.ch>
Subject Re: [DISCUSS] - Moving towards Camel 2.11 release
Date Thu, 24 Jan 2013 08:10:51 GMT


Am 24.01.13 08:39 schrieb "Claus Ibsen" unter <claus.ibsen@gmail.com>:

>On Thu, Jan 24, 2013 at 7:48 AM, Babak Vahdat
><babak.vahdat@swissonline.ch> wrote:
>> +1 to turn off the checkstyle directly inside the code itself and not
>>the
>> xml. As a concrete example we've got the  "maximum 7 ParameterNumber
>>rule"
>> being commented out since 2008 inside xml. And today in 2013 it's still
>> there!
>>
>
>+1 in the code as well. One place to edit.

Is done.

Babak

>
>> Babak
>>
>>
>> Willem.Jiang wrote
>>> 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 &lt;
>>
>>> christian.mueller@
>>
>>> &gt; 写道:
>>>
>>>> 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 &lt;
>>
>>> raul@
>>
>>> &gt; 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" &lt;
>>
>>> babak.vahdat@
>>
>>> &gt; wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> Am 23.01.13 16:16 schrieb "Claus Ibsen" unter &lt;
>>
>>> claus.ibsen@
>>
>>> &gt;:
>>>>>>
>>>>>>> On Wed, Jan 23, 2013 at 1:15 PM, Babak Vahdat
>>>>>>> &lt;
>>
>>> babak.vahdat@
>>
>>> &gt; 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-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@
>>
>>>>>>> Web: http://fusesource.com
>>>>>>> Twitter: davsclaus
>>>>>>> Blog: http://davsclaus.com
>>>>>>> Author of Camel in Action: http://www.manning.com/ibsen
>>>>
>>>>
>>>>
>>>> --
>>
>>
>>
>>
>>
>> --
>> View this message in context:
>>http://camel.465427.n5.nabble.com/DISCUSS-Moving-towards-Camel-2-11-relea
>>se-tp5725088p5726107.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