camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hadrian Zbarcea <hzbar...@gmail.com>
Subject Re: Contributing Scomp Component (was Contributing Stomp Component)
Date Fri, 08 Feb 2013 13:06:55 GMT
Hiram, that would be greet indeed.

Fwiw, my comment didn't refer to scala per se, but any component that we 
don't have the ability to support ourselves. With java at least I 
believe there are quite a few of us who could jump in and fix things, 
with scala it's less the case. And socially, what doesn't make me very 
confident is the fact that the original committers of the scala 
component went awol. From my pov, support for python and ruby are not at 
the needed quality, and they are used way more than scala.

Regarding growing the community, ok, but how to do it? I don't think the 
current form will work. Start a subproject? At one point there were 
users interested even in porting camel to .net.

Cheers
Hadrian


On 02/08/2013 07:54 AM, Hiram Chirino wrote:
> How about if we can get at least 3 committers to agree to help maintain the
> component then it should  get accepted.  I think we should make efforts to
> grow the camel community past just Java components if possible.
>
>
> On Thu, Feb 7, 2013 at 7:51 PM, Willem jiang <willem.jiang@gmail.com> wrote:
>
>> Putting the components into Apache Camel umbral could save some work of
>> contributor when we release the Camel. We add the camel-extra due to the
>> license issue only. It is hard to say no for the contributing to Apache
>> Camel if the component has the ASF license already. That is way we have
>> more then one hundred components today.
>>
>> Current the hard part is the Stomp Component is written with Scala, as we
>> have the camel-scala, I don't think why we can not host the camel-stomp
>> component except few people know how to maintain it. I think few people
>> know about jclouds, hl7,redis … but we are open mind to host these
>> components.
>>
>> --
>> Willem Jiang
>>
>> Red Hat, Inc.
>> FuseSource is now part of Red Hat
>> Web: http://www.fusesource.com | http://www.redhat.com
>> Blog: http://willemjiang.blogspot.com (http://willemjiang.blogspot.com/)
>> (English)
>>            http://jnn.iteye.com (http://jnn.javaeye.com/) (Chinese)
>> Twitter: willemjiang
>> Weibo: 姜宁willem
>>
>>
>>
>>
>>
>> On Friday, February 8, 2013 at 6:35 AM, Hadrian Zbarcea wrote:
>>
>>> I also believe Apache Camel the way it is organized now is not the place
>>> for the scomp component. We are not debating the quality of the scomp
>>> component. We know however from past experience that the community's
>>> ability to support scala based code was not at par with the rest of the
>>> code base.
>>>
>>> There are camel components developed and supported outside the ASF. We
>>> encourage and support that, so that could be an option (camel-extra was
>>> mentioned I think in another thread). There are other possibilities not
>>> yet discussed, like moving non-java artifacts into sub-projects
>>> maintained by people who are best qualified for that.
>>>
>>> All potential solutions have pros and cons, I dunno what would be more
>>> appropriate. At this point I agree with Christian, Apache Camel would
>>> probably not be a cozy home for scomp.
>>>
>>> Cheers,
>>> Hadrian
>>>
>>>
>>>
>>> On 02/07/2013 05:15 PM, Christian Müller wrote:
>>>> Please find my comments inline.
>>>>
>>>> Best,
>>>> Christian
>>>>
>>>> On Thu, Feb 7, 2013 at 9:20 PM, Henryk Konsek <hekonsek@gmail.com(mailto:
>> hekonsek@gmail.com)> wrote:
>>>>
>>>>>> Because Camel and Camel-Extra are Java based projects, I don't
>> think we
>>>>>> should integrate this component (even if it's a cool component for
>> Scala
>>>>>> guys).
>>>>>
>>>>>
>>>>>
>>>>> I'm afraid I must disagree :) .
>>>>>
>>>>> We support Scala as the 1st class citizen DSL language for Camel and
>> I
>>>>> don't see any reason why we should exclude components using Scala
>>>>> libraries.
>>>>
>>>>
>>>> The component under discussion IS WRITTEN in Scala. It's not, it
>> "only" use
>>>> a Scala library.
>>>>
>>>>>
>>>>> Also from the end-user point of view Scala is just an another
>> library.
>>>>> I could create the following route in Java DSL and I would not be
>> even
>>>>> aware that I'm using Scala under the hood. For example:
>>>>> from("jms:queue").to("someScalaComponent:foo")
>>>>
>>>>
>>>> It's not the user point of view which concerns me. I'm aware it's
>>>> transparent for the user.
>>>> Only a few committers are familiar with Scala. This is what concerns
>> me.
>>>>
>>>>>
>>>>> The core of the Camel and the Java-related components are written in
>>>>> Java, but in my humble opinion there is no reason we shouldn't
>> provide
>>>>> components written in Scala, as long as the subject of the component
>>>>> is also written in Scala.
>>>>
>>>>
>>>> Agree. That's the reason why we have a Scala component, a Scala DSL,
>> ...
>>>> But providing an integration with Stomp is not a Scala subject IMO.
>>>> And there is no reason why this component can not be developed in Java.
>>>>
>>>>>
>>>>> Maybe we could settle some "official policy" regarding Scala-related
>>>>> code for Camel?
>>>>
>>>>
>>>> I don't see the need right now. There are many other scripting
>> languages
>>>> running in a JVM (http://en.wikipedia.org/wiki/List_of_JVM_languages).
>>>> Should we also accept new components written in these languages? I
>> don't
>>>> think so...
>>>>
>>>>>
>>>>> --
>>>>> Henryk Konsek
>>>>> http://henryk-konsek.blogspot.com
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> --
>>
>>
>>
>
>

Mime
View raw message