You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@camel.apache.org by Bilgin Ibryam <bi...@gmail.com> on 2013/02/06 15:23:38 UTC
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-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: cibsen@redhat.com
> >Web: http://fusesource.com
> >Twitter: davsclaus
> >Blog: http://davsclaus.com
> >Author of Camel in Action: http://www.manning.com/ibsen
>
>
>
Re: [DISCUSS] - Moving towards Camel 2.11 release
Posted by Claus Ibsen <cl...@gmail.com>.
Thanks Biligin for adding the docs.
We have a blocker issue related to OSGi
https://issues.apache.org/jira/browse/CAMEL-6060
Which means many of the language components in OSGi dont work. I am
not sure when the issue was introduced.
Details in the ticket.
We should get that CI build up and running that only does the OSGi
testing. I have logged a JIRA ticket about that.
This would help us catch OSGi breaking faster than currently.
We are still waiting for Karaf 2.3.1 which is needed for Camel 2.11 to
run in Karaf.
On Sat, Feb 9, 2013 at 5:17 PM, Bilgin Ibryam <bi...@gmail.com> wrote:
> 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) <ap...@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
>> >
>> >
>> >
>>
>>
--
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
Re: [DISCUSS] - Moving towards Camel 2.11 release
Posted by Bilgin Ibryam <bi...@gmail.com>.
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) <ap...@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
> >
> >
> >
>
>
AW: [DISCUSS] - Moving towards Camel 2.11 release
Posted by "Jan Matèrne (jhm)" <ap...@materne.de>.
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
>
>
>