camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Müller <christian.muel...@gmail.com>
Subject Re: Contributing Scomp Component (was Contributing Stomp Component)
Date Thu, 07 Feb 2013 22:15:21 GMT
Please find my comments inline.

Best,
Christian

On Thu, Feb 7, 2013 at 9:20 PM, Henryk Konsek <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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message