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 <hekon...@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
--
