camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hiram Chirino <hi...@hiramchirino.com>
Subject Re: Contributing Scomp Component (was Contributing Stomp Component)
Date Fri, 08 Feb 2013 12:54:59 GMT
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
> > >
> > >
> > >
> > >
> > >
> > > --
>
>
>


-- 

**

*Hiram Chirino*

*Engineering | Red Hat, Inc.*

*hchirino@redhat.com <hchirino@redhat.com> | fusesource.com | redhat.com*

*skype: hiramchirino | twitter: @hiramchirino<http://twitter.com/hiramchirino>
*

*blog: Hiram Chirino's Bit Mojo <http://hiramchirino.com/blog/>*

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message