You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@camel.apache.org by iandebeer <ia...@zenaptix.com> on 2013/02/04 07:14:20 UTC
Re: Contributing Scomp Component (was Contributing Stomp Component)
Hi
I have created a pull request for Scomp that contains all the modifications I made to that project. I have discussed this with Dejan Bosanac and I am waiting for the pull request to be incorporated. One small snag is that the the test uses an imbedded Apollo broker and because of the Scala 2.10 dependency we now need the latest SNAPSHOT release of Apollo to run the tests. I hope that a Scala 2.10 compliant release of Apollo is planned for the near future.
I have moved the camel-scomp component into a a new camel-scomp repo: https://github.com/zenaptix/camel-scomp.git with all the refactorings you suggested.
(I am actually happy for the name change, due to this unfortunate ambiguity: http://www.urbandictionary.com/define.php?term=camel%20stomp)
So once we have Scomp updated we are good to go.
Regards
Ian
On 01 Feb 2013, at 9:09 AM, hekonsek [via Camel] <ml...@n5.nabble.com> wrote:
> > That is a good approach.
> > ..
> > I am waiting for a response.
>
> Great :) Just keep me in the loop.
>
> --
> Henryk Konsek
> http://henryk-konsek.blogspot.com
>
>
> If you reply to this email, your message will be added to the discussion below:
> http://camel.465427.n5.nabble.com/Contributing-Apollo-Component-tp5726153p5726700.html
> To unsubscribe from Contributing Apollo Component, click here.
> NAML
--
View this message in context: http://camel.465427.n5.nabble.com/Re-Contributing-Scomp-Component-was-Contributing-Stomp-Component-tp5726868.html
Sent from the Camel Development mailing list archive at Nabble.com.
Re: Contributing Scomp Component (was Contributing Stomp Component)
Posted by Johan Edstrom <se...@gmail.com>.
I have to say I kinda agree with this.
We could mark a component as possibly "less quickly patched",
but nixing contributions on a component level seems kinda wrong to me...
On Feb 7, 2013, at 1:20 PM, Henryk Konsek <he...@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.
>
> 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")
>
> 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.
>
> Maybe we could settle some "official policy" regarding Scala-related
> code for Camel?
>
> --
> Henryk Konsek
> http://henryk-konsek.blogspot.com
Re: Contributing Scomp Component (was Contributing Stomp Component)
Posted by Henryk Konsek <he...@gmail.com>.
> Hadrian:
> 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.
This is changing. Scala is getting more popular among Java people. And
this trend is visible almost within our community. Year ago I wouldn't
commit anything in Scala, now I'm waiting for another of my pull
requests to be merged into the Spring Scala [1] project. In the year
from this point forward probably more of us will adopt Scala for their
skillsets. Keep in mind also that rejecting Scala contributions will
result in rejecting the Scala people from our community. This is
Catch-22 kind of situation.
> Christian:
> 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.
Yes it is - maintenance of Java code making use of Scala libraries not
designed to be accessed from Java is a hell. It is technically
possible, but tough in reality. This is unnecessary maintenance burden
we can easily avoid just by writing the component in Scala.
> Christian:
> 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...
First of all Scala is bit different than ordinary scripting language,
because it is often (and successfully) considered by users as the
replacement for Java in the context of the messaging-related systems.
Also, let's say Groovy, can be integrated into Java component more
easily than Scala.
> Willem:
> I think few people know about jclouds, hl7,redis …
> but we are open mind to host these components.
Very good point.
To summarize a little bit - I strongly believe that we as development
team can handle supporting Scala components. I also believe that
throwing away Scala contributions from our community will not be good
for it in the long run.
Best regards.
[1] http://blog.springsource.org/2012/12/10/introducing-spring-scala
--
Henryk Konsek
http://henryk-konsek.blogspot.com
Re: Contributing Scomp Component (was Contributing Stomp
Component)
Posted by Willem jiang <wi...@gmail.com>.
Oh, I don't agree with that Scomp component is written in Scala we should find other place to host it.
As an open source project we should alway encourage people to contribute, and we can always find someone who willing to maintain the code, if we have lots of users to use component.
--
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 9:34 AM, Hadrian Zbarcea wrote:
> Willem, I know all that. I understand it makes sense from the
> contributor's point of view. It saves contributors time, effort and
> costs. It ensures the their component will continue to work with future
> versions of camel. That benefits the community too. Personally I applaud
> that attitude.
>
> However, you completely miss the mark. You seem to be disagreeing, yet
> you come with arguments we all agree with. If you want to build
> consensus for accepting this component, address the concerns raised in
> the previous mails.
>
> Cheers,
> Hadrian
>
>
>
> On 02/07/2013 07:51 PM, Willem jiang 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
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > --
Re: Contributing Scomp Component (was Contributing Stomp Component)
Posted by Hadrian Zbarcea <hz...@gmail.com>.
Willem, I know all that. I understand it makes sense from the
contributor's point of view. It saves contributors time, effort and
costs. It ensures the their component will continue to work with future
versions of camel. That benefits the community too. Personally I applaud
that attitude.
However, you completely miss the mark. You seem to be disagreeing, yet
you come with arguments we all agree with. If you want to build
consensus for accepting this component, address the concerns raised in
the previous mails.
Cheers,
Hadrian
On 02/07/2013 07:51 PM, Willem jiang 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
>>>
>>>
>>>
>>>
>>>
>>> --
>
>
Re: Contributing Scomp Component (was Contributing Stomp Component)
Posted by Henryk Konsek <he...@gmail.com>.
> Hiram:
> How about if we can get at least 3 committers to agree to help maintain the
> component then it should get accepted.
Maybe instead we could establish a kind of "Scala team" among the
Camel committers? These volunteers could declare that they would
handle Scala-related escalations in the first place. As you might
expected, I'm the first volunteer. :)
If there will be too few of Scala volunteers to keep the Scala code
neat and clean, then we could think about creating subproject for
Scala.
--
Henryk Konsek
http://henryk-konsek.blogspot.com
Re: Contributing Scomp Component (was Contributing Stomp Component)
Posted by Hadrian Zbarcea <hz...@gmail.com>.
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 <wi...@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
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> --
>>
>>
>>
>
>
Re: Contributing Scomp Component (was Contributing Stomp Component)
Posted by Hiram Chirino <hi...@hiramchirino.com>.
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 <wi...@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
> > >
> > >
> > >
> > >
> > >
> > > --
>
>
>
--
**
*Hiram Chirino*
*Engineering | Red Hat, Inc.*
*hchirino@redhat.com <hc...@redhat.com> | fusesource.com | redhat.com*
*skype: hiramchirino | twitter: @hiramchirino<http://twitter.com/hiramchirino>
*
*blog: Hiram Chirino's Bit Mojo <http://hiramchirino.com/blog/>*
Re: Contributing Scomp Component (was Contributing Stomp
Component)
Posted by Willem jiang <wi...@gmail.com>.
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
> >
> >
> >
> >
> >
> > --
Re: Contributing Scomp Component (was Contributing Stomp Component)
Posted by Hadrian Zbarcea <hz...@gmail.com>.
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 <he...@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
>>
>
>
>
> --
>
Re: Contributing Scomp Component (was Contributing Stomp Component)
Posted by Christian Müller <ch...@gmail.com>.
Please find my comments inline.
Best,
Christian
On Thu, Feb 7, 2013 at 9:20 PM, Henryk Konsek <he...@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
>
--
Re: Contributing Scomp Component (was Contributing Stomp Component)
Posted by Henryk Konsek <he...@gmail.com>.
> 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.
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")
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.
Maybe we could settle some "official policy" regarding Scala-related
code for Camel?
--
Henryk Konsek
http://henryk-konsek.blogspot.com
Re: Contributing Scomp Component (was Contributing Stomp Component)
Posted by Ian de Beer <ia...@zenaptix.com>.
My need for this component arose from wanting to connect to ActiveMQ Apollo from within an Akka actor. Both of these (Akka and Apollo), have no Scala bias and works just fine in Java projects. As I suggested, it would probably be a better fit to provide the component as an Apollo-Camel contribution simillar to ActiveMQ-Camel, but being outside of ASF and Fuse, I am not privy to any plans for Apollo.
I have merged the Scomp code with the original Scomp project in Github. I also raised a Sonatype Jira request to have the Scomp jars made available in the public repo. I shall do the same for the Camel component, so if you want reference it in your component page, you are welcome.
Kind regards
Ian
Sent from my iPad
On 06 Feb 2013, at 23:50, Christian Müller <ch...@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).
> As Claus mentioned, we can add a link from our components page to your
> GitHub project, if you want.
>
> Best,
> Christian
>
> On Mon, Feb 4, 2013 at 7:14 AM, iandebeer <ia...@zenaptix.com> wrote:
>
>> Hi
>> I have created a pull request for Scomp that contains all the
>> modifications I made to that project. I have discussed this with Dejan
>> Bosanac and I am waiting for the pull request to be incorporated. One small
>> snag is that the the test uses an imbedded Apollo broker and because of the
>> Scala 2.10 dependency we now need the latest SNAPSHOT release of Apollo to
>> run the tests. I hope that a Scala 2.10 compliant release of Apollo is
>> planned for the near future.
>> I have moved the camel-scomp component into a a new camel-scomp repo:
>> https://github.com/zenaptix/camel-scomp.git with all the refactorings you
>> suggested.
>> (I am actually happy for the name change, due to this unfortunate
>> ambiguity: http://www.urbandictionary.com/define.php?term=camel%20stomp)
>> So once we have Scomp updated we are good to go.
>> Regards
>> Ian
>>
>>
>> On 01 Feb 2013, at 9:09 AM, hekonsek [via Camel] <
>> ml-node+s465427n5726700h93@n5.nabble.com> wrote:
>>
>>>> That is a good approach.
>>>> ..
>>>> I am waiting for a response.
>>>
>>> Great :) Just keep me in the loop.
>>>
>>> --
>>> Henryk Konsek
>>> http://henryk-konsek.blogspot.com
>>>
>>>
>>> If you reply to this email, your message will be added to the discussion
>> below:
>>>
>> http://camel.465427.n5.nabble.com/Contributing-Apollo-Component-tp5726153p5726700.html
>>> To unsubscribe from Contributing Apollo Component, click here.
>>> NAML
>>
>>
>>
>>
>>
>> --
>> View this message in context:
>> http://camel.465427.n5.nabble.com/Re-Contributing-Scomp-Component-was-Contributing-Stomp-Component-tp5726868.html
>> Sent from the Camel Development mailing list archive at Nabble.com.
>
>
>
>
> --
Re: Contributing Scomp Component (was Contributing Stomp Component)
Posted by Christian Müller <ch...@gmail.com>.
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).
As Claus mentioned, we can add a link from our components page to your
GitHub project, if you want.
Best,
Christian
On Mon, Feb 4, 2013 at 7:14 AM, iandebeer <ia...@zenaptix.com> wrote:
> Hi
> I have created a pull request for Scomp that contains all the
> modifications I made to that project. I have discussed this with Dejan
> Bosanac and I am waiting for the pull request to be incorporated. One small
> snag is that the the test uses an imbedded Apollo broker and because of the
> Scala 2.10 dependency we now need the latest SNAPSHOT release of Apollo to
> run the tests. I hope that a Scala 2.10 compliant release of Apollo is
> planned for the near future.
> I have moved the camel-scomp component into a a new camel-scomp repo:
> https://github.com/zenaptix/camel-scomp.git with all the refactorings you
> suggested.
> (I am actually happy for the name change, due to this unfortunate
> ambiguity: http://www.urbandictionary.com/define.php?term=camel%20stomp)
> So once we have Scomp updated we are good to go.
> Regards
> Ian
>
>
> On 01 Feb 2013, at 9:09 AM, hekonsek [via Camel] <
> ml-node+s465427n5726700h93@n5.nabble.com> wrote:
>
> > > That is a good approach.
> > > ..
> > > I am waiting for a response.
> >
> > Great :) Just keep me in the loop.
> >
> > --
> > Henryk Konsek
> > http://henryk-konsek.blogspot.com
> >
> >
> > If you reply to this email, your message will be added to the discussion
> below:
> >
> http://camel.465427.n5.nabble.com/Contributing-Apollo-Component-tp5726153p5726700.html
> > To unsubscribe from Contributing Apollo Component, click here.
> > NAML
>
>
>
>
>
> --
> View this message in context:
> http://camel.465427.n5.nabble.com/Re-Contributing-Scomp-Component-was-Contributing-Stomp-Component-tp5726868.html
> Sent from the Camel Development mailing list archive at Nabble.com.
--
Re: Contributing Scomp Component (was Contributing Stomp Component)
Posted by Henryk Konsek <he...@gmail.com>.
> So once we have Scomp updated we are good to go.
First of all we need to figure out where the component should go, as
apparently there is some disagreement related to the proper place for
the Scala-related components.
BTW Camel Stomp definition made my day :P .
--
Henryk Konsek
http://henryk-konsek.blogspot.com