You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@servicemix.apache.org by Guillaume Nodet <gn...@gmail.com> on 2011/07/08 10:12:02 UTC
[smx5] Scala based (was Re: Profiling stragegy)
Yeah, definitely. I don't think we've really discussed that point. I used
scala for the following reasons right now:
* the manual / web console (almost empty now) are based on scalate which
is focusing on scala
* it forces me to learn Scala ;-)
I agree we need to make sure we all agree on which direction to go.
I don't have much knowledge of Scala yet so I'm far less productive than
when using Java right now (I guess a lot of us are newbies too).
I was going to try finding benefits and list them, but I just came across
James's blog entry:
http://macstrac.blogspot.com/2009/04/scala-as-long-term-replacement-for.html
In short, Scala is just a better language I think. How long will we have to
wait for java closures? And even when they come, it will be in Java 7 or 8
which we won't be able to use until a few years.
Anyway, I know I'll be a little less productive at least for a few months,
but I think the long term benefits are greater than the cost.
On Fri, Jul 8, 2011 at 09:59, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
> Hi Guillaume,
>
> thanks a bunch, it looks very good.
>
> I see that you implemented in Scala.
>
> Does it mean that SMX5 will by Scala based ?
> We had discussion on the mailing list around that but I didn't see an
> agreement about that.
>
> Maybe, we should start a vote to see if the community is ready to go to
> Scala for SMX.
>
> WDYT ?
>
> Regards
> JB
>
>
> On 07/08/2011 09:56 AM, Guillaume Nodet wrote:
>
>> I've been experimenting with a first value added feature for camel routes
>> deployed in smx5.
>> The idea is to have a profiling strategy similar to a java profiler.
>> The output I have in my test is the following:
>>
>> Processor Count Time Total
>> Route[[From[direct:a]] -> [To[mock:p...] 0 0 3536
>> To[mock:polyglot] 1000 149 149
>> Choice[[When[{org.apache.**camel.sca...] 1000 63 3386
>> When[{org.apache.camel.scala.**Sca...] 1000 2208 2277
>> To[mock:english] 328 69 69
>> When[{org.apache.camel.scala.**Sca...] 672 74 976
>> To[mock:dutch] 339 74 74
>> Delay[{2} -> []] 339 727 727
>> To[mock:german] 339 100 100
>> Otherwise[[To[mock:french]]] 333 8 69
>> To[mock:french] 333 60 60
>>
>>
>> And the route is defined using the scala DSL as:
>>
>> context.addRoutes(new RouteBuilder {
>> "direct:a" ==> {
>> to("mock:polyglot")
>> choice {
>> when( (e: Exchange) => { sleep(); e.in == "<hello/>" }) {
>> to ("mock:english")
>> }
>> when(_.in == "<hallo/>") {
>> to("mock:dutch")
>> delay( 2 ms )
>> to("mock:german")
>> }
>> otherwise to ("mock:french")
>> }
>> }
>> });
>>
>> This currently requires some modifications to camel which I've done
>> locally,
>> so you won't really be able to experiment with it at this point, but I
>> just
>> wanted to give a heads up, as I found this feature quite interesting.
>>
>>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
--
------------------------
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: [smx5] Scala based (was Re: Profiling stragegy)
Posted by Charles Moulliard <cm...@gmail.com>.
Hi,
Before to take the decision to use or not scala, we should also
considering the impact of this choice for our users/committers
community and customers. Are they ready to use a Scala project or a
Apache project combining scala + java ? What will be the reaction of
certain committers not interested for developing in Scala language ?
We could potentially close the doors to new users/committers
interested by SMX5. BTW, this could be transparent for people in
charge to operate SMX5 platform but what will be their reaction when
developer will ask to start a profiler tool on SMX5 or to debug
remotely. Times are changing and Java language also Do we have to
consider to abandon Java simply because Scala offers some better
options to resolve asynch, ... Java has been adopted as "Enterprise"
language but I'm not sure that this is the case right now for Scala
which exist since 10 years
Regards,
Charles Moulliard
Apache Committer
Blog : http://cmoulliard.blogspot.com
Twitter : http://twitter.com/cmoulliard
Linkedin : http://www.linkedin.com/in/charlesmoulliard
Skype: cmoulliard
On Fri, Jul 8, 2011 at 11:03 AM, James Strachan <ja...@fusesource.com> wrote:
> BTW the main reason for using Scala on ActiveMQ Apollo wasn't just to
> get a 'better Java' - it was to avoid loads of inefficient
> synchronized blocks which are very easy to deadlock leading to really
> hairy asynchronous code thats a nightmare to edit & maintain - you can
> use much simpler code to read & write using the Scala block structure
> - in much the same way as the Scala / ScalaZ DSLs for Camel are much
> easier to read and write and don't have the block syntax smells that
> the Java DSL has (the java .begin() and .end() calls for example).
>
> For any kind of concurrent or asynchronous code this is a massive win
> (never mind the amazing collections library, function composition,
> pattern matching, type inference, traits, arrays actually being useful
> and nice to use and huge lack of boilerplate).
>
> In Scala things like HawtDispatch or Scala / Akka
> actors/futures/promises can be used to simplify things like
> asynchronous coding...
> http://hawtdispatch.fusesource.org/
> http://akka.io/
>
>
> On 8 July 2011 09:47, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
>> Thanks James and Guillaume for your advice :)
>>
>> Let me take a look on all these resources :)
>>
>> Regards
>> JB
>>
>> On 07/08/2011 10:43 AM, James Strachan wrote:
>>>
>>> On 8 July 2011 09:31, Guillaume Nodet<gn...@gmail.com> wrote:
>>>>
>>>> On Fri, Jul 8, 2011 at 10:24, Jean-Baptiste Onofré<jb...@nanthrax.net>
>>>> wrote:
>>>>
>>>>> Thanks Guillaume for the pointer and explanation.
>>>>>
>>>>> Before voting, I'm going to read the James' blog, review your code, and
>>>>> a
>>>>> quick try by myself.
>>>>>
>>>>> I would like to evaluate also what is the impact in term of Apache/IT:
>>>>> maven, hudson/jenkins continuous integration, etc.
>>>>>
>>>>
>>>> This has no impact afaik, it's just a different maven plugin. Also note
>>>> that the scala compiler can actually compile java code at the same time,
>>>> so
>>>> you can mix scala and java in the same project without any problems.
>>>
>>> Agreed. For an example of a project thats working at Apache using Java
>>> and Scala together, check out ActiveMQ Apollo which 1.0-beta 4 was
>>> just released
>>> http://activemq.apache.org/apollo/
>>>
>>
>> --
>> Jean-Baptiste Onofré
>> jbonofre@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
>
>
>
> --
> James
> -------
> FuseSource
> Email: james@fusesource.com
> Web: http://fusesource.com
> Twitter: jstrachan, fusenews
> Blog: http://macstrac.blogspot.com/
>
> Open Source Integration and Messaging
>
Re: [smx5] Scala based (was Re: Profiling stragegy)
Posted by James Strachan <ja...@fusesource.com>.
BTW the main reason for using Scala on ActiveMQ Apollo wasn't just to
get a 'better Java' - it was to avoid loads of inefficient
synchronized blocks which are very easy to deadlock leading to really
hairy asynchronous code thats a nightmare to edit & maintain - you can
use much simpler code to read & write using the Scala block structure
- in much the same way as the Scala / ScalaZ DSLs for Camel are much
easier to read and write and don't have the block syntax smells that
the Java DSL has (the java .begin() and .end() calls for example).
For any kind of concurrent or asynchronous code this is a massive win
(never mind the amazing collections library, function composition,
pattern matching, type inference, traits, arrays actually being useful
and nice to use and huge lack of boilerplate).
In Scala things like HawtDispatch or Scala / Akka
actors/futures/promises can be used to simplify things like
asynchronous coding...
http://hawtdispatch.fusesource.org/
http://akka.io/
On 8 July 2011 09:47, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
> Thanks James and Guillaume for your advice :)
>
> Let me take a look on all these resources :)
>
> Regards
> JB
>
> On 07/08/2011 10:43 AM, James Strachan wrote:
>>
>> On 8 July 2011 09:31, Guillaume Nodet<gn...@gmail.com> wrote:
>>>
>>> On Fri, Jul 8, 2011 at 10:24, Jean-Baptiste Onofré<jb...@nanthrax.net>
>>> wrote:
>>>
>>>> Thanks Guillaume for the pointer and explanation.
>>>>
>>>> Before voting, I'm going to read the James' blog, review your code, and
>>>> a
>>>> quick try by myself.
>>>>
>>>> I would like to evaluate also what is the impact in term of Apache/IT:
>>>> maven, hudson/jenkins continuous integration, etc.
>>>>
>>>
>>> This has no impact afaik, it's just a different maven plugin. Also note
>>> that the scala compiler can actually compile java code at the same time,
>>> so
>>> you can mix scala and java in the same project without any problems.
>>
>> Agreed. For an example of a project thats working at Apache using Java
>> and Scala together, check out ActiveMQ Apollo which 1.0-beta 4 was
>> just released
>> http://activemq.apache.org/apollo/
>>
>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
--
James
-------
FuseSource
Email: james@fusesource.com
Web: http://fusesource.com
Twitter: jstrachan, fusenews
Blog: http://macstrac.blogspot.com/
Open Source Integration and Messaging
Re: [smx5] Scala based (was Re: Profiling stragegy)
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Thanks James and Guillaume for your advice :)
Let me take a look on all these resources :)
Regards
JB
On 07/08/2011 10:43 AM, James Strachan wrote:
> On 8 July 2011 09:31, Guillaume Nodet<gn...@gmail.com> wrote:
>> On Fri, Jul 8, 2011 at 10:24, Jean-Baptiste Onofré<jb...@nanthrax.net> wrote:
>>
>>> Thanks Guillaume for the pointer and explanation.
>>>
>>> Before voting, I'm going to read the James' blog, review your code, and a
>>> quick try by myself.
>>>
>>> I would like to evaluate also what is the impact in term of Apache/IT:
>>> maven, hudson/jenkins continuous integration, etc.
>>>
>>
>> This has no impact afaik, it's just a different maven plugin. Also note
>> that the scala compiler can actually compile java code at the same time, so
>> you can mix scala and java in the same project without any problems.
>
> Agreed. For an example of a project thats working at Apache using Java
> and Scala together, check out ActiveMQ Apollo which 1.0-beta 4 was
> just released
> http://activemq.apache.org/apollo/
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: [smx5] Scala based (was Re: Profiling stragegy)
Posted by James Strachan <ja...@fusesource.com>.
On 8 July 2011 09:31, Guillaume Nodet <gn...@gmail.com> wrote:
> On Fri, Jul 8, 2011 at 10:24, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
>
>> Thanks Guillaume for the pointer and explanation.
>>
>> Before voting, I'm going to read the James' blog, review your code, and a
>> quick try by myself.
>>
>> I would like to evaluate also what is the impact in term of Apache/IT:
>> maven, hudson/jenkins continuous integration, etc.
>>
>
> This has no impact afaik, it's just a different maven plugin. Also note
> that the scala compiler can actually compile java code at the same time, so
> you can mix scala and java in the same project without any problems.
Agreed. For an example of a project thats working at Apache using Java
and Scala together, check out ActiveMQ Apollo which 1.0-beta 4 was
just released
http://activemq.apache.org/apollo/
--
James
-------
FuseSource
Email: james@fusesource.com
Web: http://fusesource.com
Twitter: jstrachan, fusenews
Blog: http://macstrac.blogspot.com/
Open Source Integration and Messaging
Re: [smx5] Scala based (was Re: Profiling stragegy)
Posted by Guillaume Nodet <gn...@gmail.com>.
On Fri, Jul 8, 2011 at 10:24, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
> Thanks Guillaume for the pointer and explanation.
>
> Before voting, I'm going to read the James' blog, review your code, and a
> quick try by myself.
>
> I would like to evaluate also what is the impact in term of Apache/IT:
> maven, hudson/jenkins continuous integration, etc.
>
This has no impact afaik, it's just a different maven plugin. Also note
that the scala compiler can actually compile java code at the same time, so
you can mix scala and java in the same project without any problems.
>
> I will send my vote asap :)
>
> Thanks again
> Regards
> JB
>
>
> On 07/08/2011 10:12 AM, Guillaume Nodet wrote:
>
>> Yeah, definitely. I don't think we've really discussed that point. I
>> used
>> scala for the following reasons right now:
>> * the manual / web console (almost empty now) are based on scalate which
>> is focusing on scala
>> * it forces me to learn Scala ;-)
>>
>> I agree we need to make sure we all agree on which direction to go.
>> I don't have much knowledge of Scala yet so I'm far less productive than
>> when using Java right now (I guess a lot of us are newbies too).
>>
>> I was going to try finding benefits and list them, but I just came across
>> James's blog entry:
>>
>> http://macstrac.blogspot.com/**2009/04/scala-as-long-term-**
>> replacement-for.html<http://macstrac.blogspot.com/2009/04/scala-as-long-term-replacement-for.html>
>> In short, Scala is just a better language I think. How long will we have
>> to
>> wait for java closures? And even when they come, it will be in Java 7 or
>> 8
>> which we won't be able to use until a few years.
>>
>> Anyway, I know I'll be a little less productive at least for a few months,
>> but I think the long term benefits are greater than the cost.
>>
>> On Fri, Jul 8, 2011 at 09:59, Jean-Baptiste Onofré<jb...@nanthrax.net>
>> wrote:
>>
>> Hi Guillaume,
>>>
>>> thanks a bunch, it looks very good.
>>>
>>> I see that you implemented in Scala.
>>>
>>> Does it mean that SMX5 will by Scala based ?
>>> We had discussion on the mailing list around that but I didn't see an
>>> agreement about that.
>>>
>>> Maybe, we should start a vote to see if the community is ready to go to
>>> Scala for SMX.
>>>
>>> WDYT ?
>>>
>>> Regards
>>> JB
>>>
>>>
>>> On 07/08/2011 09:56 AM, Guillaume Nodet wrote:
>>>
>>> I've been experimenting with a first value added feature for camel
>>>> routes
>>>> deployed in smx5.
>>>> The idea is to have a profiling strategy similar to a java profiler.
>>>> The output I have in my test is the following:
>>>>
>>>> Processor Count Time Total
>>>> Route[[From[direct:a]] -> [To[mock:p...] 0 0 3536
>>>> To[mock:polyglot] 1000 149 149
>>>> Choice[[When[{org.apache.****camel.sca...] 1000 63 3386
>>>> When[{org.apache.camel.scala.****Sca...] 1000 2208 2277
>>>> To[mock:english] 328 69 69
>>>> When[{org.apache.camel.scala.****Sca...] 672 74 976
>>>> To[mock:dutch] 339 74 74
>>>> Delay[{2} -> []] 339 727 727
>>>> To[mock:german] 339 100 100
>>>> Otherwise[[To[mock:french]]] 333 8 69
>>>> To[mock:french] 333 60 60
>>>>
>>>>
>>>> And the route is defined using the scala DSL as:
>>>>
>>>> context.addRoutes(new RouteBuilder {
>>>> "direct:a" ==> {
>>>> to("mock:polyglot")
>>>> choice {
>>>> when( (e: Exchange) => { sleep(); e.in == "<hello/>" }) {
>>>> to ("mock:english")
>>>> }
>>>> when(_.in == "<hallo/>") {
>>>> to("mock:dutch")
>>>> delay( 2 ms )
>>>> to("mock:german")
>>>> }
>>>> otherwise to ("mock:french")
>>>> }
>>>> }
>>>> });
>>>>
>>>> This currently requires some modifications to camel which I've done
>>>> locally,
>>>> so you won't really be able to experiment with it at this point, but I
>>>> just
>>>> wanted to give a heads up, as I found this feature quite interesting.
>>>>
>>>>
>>>> --
>>> Jean-Baptiste Onofré
>>> jbonofre@apache.org
>>> http://blog.nanthrax.net
>>> Talend - http://www.talend.com
>>>
>>>
>>
>>
>>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
--
------------------------
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: [smx5] Scala based (was Re: Profiling stragegy)
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Thanks Guillaume for the pointer and explanation.
Before voting, I'm going to read the James' blog, review your code, and
a quick try by myself.
I would like to evaluate also what is the impact in term of Apache/IT:
maven, hudson/jenkins continuous integration, etc.
I will send my vote asap :)
Thanks again
Regards
JB
On 07/08/2011 10:12 AM, Guillaume Nodet wrote:
> Yeah, definitely. I don't think we've really discussed that point. I used
> scala for the following reasons right now:
> * the manual / web console (almost empty now) are based on scalate which
> is focusing on scala
> * it forces me to learn Scala ;-)
>
> I agree we need to make sure we all agree on which direction to go.
> I don't have much knowledge of Scala yet so I'm far less productive than
> when using Java right now (I guess a lot of us are newbies too).
>
> I was going to try finding benefits and list them, but I just came across
> James's blog entry:
>
> http://macstrac.blogspot.com/2009/04/scala-as-long-term-replacement-for.html
> In short, Scala is just a better language I think. How long will we have to
> wait for java closures? And even when they come, it will be in Java 7 or 8
> which we won't be able to use until a few years.
>
> Anyway, I know I'll be a little less productive at least for a few months,
> but I think the long term benefits are greater than the cost.
>
> On Fri, Jul 8, 2011 at 09:59, Jean-Baptiste Onofré<jb...@nanthrax.net> wrote:
>
>> Hi Guillaume,
>>
>> thanks a bunch, it looks very good.
>>
>> I see that you implemented in Scala.
>>
>> Does it mean that SMX5 will by Scala based ?
>> We had discussion on the mailing list around that but I didn't see an
>> agreement about that.
>>
>> Maybe, we should start a vote to see if the community is ready to go to
>> Scala for SMX.
>>
>> WDYT ?
>>
>> Regards
>> JB
>>
>>
>> On 07/08/2011 09:56 AM, Guillaume Nodet wrote:
>>
>>> I've been experimenting with a first value added feature for camel routes
>>> deployed in smx5.
>>> The idea is to have a profiling strategy similar to a java profiler.
>>> The output I have in my test is the following:
>>>
>>> Processor Count Time Total
>>> Route[[From[direct:a]] -> [To[mock:p...] 0 0 3536
>>> To[mock:polyglot] 1000 149 149
>>> Choice[[When[{org.apache.**camel.sca...] 1000 63 3386
>>> When[{org.apache.camel.scala.**Sca...] 1000 2208 2277
>>> To[mock:english] 328 69 69
>>> When[{org.apache.camel.scala.**Sca...] 672 74 976
>>> To[mock:dutch] 339 74 74
>>> Delay[{2} -> []] 339 727 727
>>> To[mock:german] 339 100 100
>>> Otherwise[[To[mock:french]]] 333 8 69
>>> To[mock:french] 333 60 60
>>>
>>>
>>> And the route is defined using the scala DSL as:
>>>
>>> context.addRoutes(new RouteBuilder {
>>> "direct:a" ==> {
>>> to("mock:polyglot")
>>> choice {
>>> when( (e: Exchange) => { sleep(); e.in == "<hello/>" }) {
>>> to ("mock:english")
>>> }
>>> when(_.in == "<hallo/>") {
>>> to("mock:dutch")
>>> delay( 2 ms )
>>> to("mock:german")
>>> }
>>> otherwise to ("mock:french")
>>> }
>>> }
>>> });
>>>
>>> This currently requires some modifications to camel which I've done
>>> locally,
>>> so you won't really be able to experiment with it at this point, but I
>>> just
>>> wanted to give a heads up, as I found this feature quite interesting.
>>>
>>>
>> --
>> Jean-Baptiste Onofré
>> jbonofre@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
>
>
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: [smx5] Scala based (was Re: Profiling stragegy)
Posted by Gert Vanthienen <ge...@gmail.com>.
L.S.,
Let me add a page with a few of these book/article/... references and
link it to http://servicemix.apache.org/staging/developers/source/smx5-source.html
I'd also be more than happy to help people out with questions on Scala
itself, so just post any doubts/questions on the dev list - it's a
great language to learn and I agree with Johan that the extra
possibilities to cross-communicate about how to go about things is
actually a nice plus from a community point-of-view.
Regards,
Gert Vanthienen
------------------------
FuseSource
Web: http://fusesource.com
Blog: http://gertvanthienen.blogspot.com/
On Mon, Jul 18, 2011 at 11:14 AM, Johan Edstrom <se...@gmail.com> wrote:
> For those who want to,
> I'd recommend Programming Scala 2nd Ed.
> THere is also a Pragmatic Scala book, both are good reads.
>
> /je
>
> On Jul 18, 2011, at 3:11 AM, Ioannis Canellos wrote:
>
>> Could we ask the Apollo team, how they handled those issues? And what impact
>> had scala to the development team and the community?
>>
>> --
>> *Ioannis Canellos*
>> *
>> http://iocanel.blogspot.com
>>
>> Apache Karaf <http://karaf.apache.org/> Committer & PMC
>> Apache ServiceMix <http://servicemix.apache.org/> Committer
>> *
>
>
Re: [smx5] Scala based (was Re: Profiling stragegy)
Posted by Johan Edstrom <se...@gmail.com>.
For those who want to,
I'd recommend Programming Scala 2nd Ed.
THere is also a Pragmatic Scala book, both are good reads.
/je
On Jul 18, 2011, at 3:11 AM, Ioannis Canellos wrote:
> Could we ask the Apollo team, how they handled those issues? And what impact
> had scala to the development team and the community?
>
> --
> *Ioannis Canellos*
> *
> http://iocanel.blogspot.com
>
> Apache Karaf <http://karaf.apache.org/> Committer & PMC
> Apache ServiceMix <http://servicemix.apache.org/> Committer
> *
Re: [smx5] Scala based (was Re: Profiling stragegy)
Posted by Ioannis Canellos <io...@gmail.com>.
Could we ask the Apollo team, how they handled those issues? And what impact
had scala to the development team and the community?
--
*Ioannis Canellos*
*
http://iocanel.blogspot.com
Apache Karaf <http://karaf.apache.org/> Committer & PMC
Apache ServiceMix <http://servicemix.apache.org/> Committer
*
Re: [smx5] Scala based (was Re: Profiling stragegy)
Posted by Johan Edstrom <se...@gmail.com>.
I think part 2 could be seen as a fun exercise if one were so inclined.
It'll also mean that we'll have to cross communicate more to help each other,
who knows - that might just be a big plus.
:)
On Jul 18, 2011, at 1:14 AM, Guillaume Nodet wrote:
> I think the discussion stopped a few days ago, so I'll try to sum up.
> There has been no strong opposition to move to Scala and overall it
> would be seen as a good thing. However it may affect users and / or
> servicemix developer communities and some concerns have been raised:
> * for users, I think there's a consensus to make sure that
> developing parts of ServiceMix in scala does not affect downstream
> users so that they can't still continue using java.
> * for developers: switching to Scala might push some ServiceMix
> committers down to learning a new language which would take some time
> they may not be ready to spend, and may lower the number of ServiceMix
> users who could have contributed to the project and become committers
>
> For the first point, I think this means that any API / SPI would have
> to be developed in Java rather than directly in Scala. That would
> address most of the problems as the only effect on users would be the
> need to have the scala libraries on the classpath or deployed in osgi.
> For the second point, I agree that may be slightly more difficult to
> address. New features could be developed in Java and contributed, but
> for patches, users/developers would have to understand scala a bit.
>
>
> On Fri, Jul 8, 2011 at 10:12, Guillaume Nodet <gn...@gmail.com> wrote:
>> Yeah, definitely. I don't think we've really discussed that point. I used
>> scala for the following reasons right now:
>> * the manual / web console (almost empty now) are based on scalate which
>> is focusing on scala
>> * it forces me to learn Scala ;-)
>> I agree we need to make sure we all agree on which direction to go.
>> I don't have much knowledge of Scala yet so I'm far less productive than
>> when using Java right now (I guess a lot of us are newbies too).
>> I was going to try finding benefits and list them, but I just came across
>> James's blog entry:
>> http://macstrac.blogspot.com/2009/04/scala-as-long-term-replacement-for.html
>> In short, Scala is just a better language I think. How long will we have to
>> wait for java closures? And even when they come, it will be in Java 7 or 8
>> which we won't be able to use until a few years.
>> Anyway, I know I'll be a little less productive at least for a few months,
>> but I think the long term benefits are greater than the cost.
>> On Fri, Jul 8, 2011 at 09:59, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
>>>
>>> Hi Guillaume,
>>>
>>> thanks a bunch, it looks very good.
>>>
>>> I see that you implemented in Scala.
>>>
>>> Does it mean that SMX5 will by Scala based ?
>>> We had discussion on the mailing list around that but I didn't see an
>>> agreement about that.
>>>
>>> Maybe, we should start a vote to see if the community is ready to go to
>>> Scala for SMX.
>>>
>>> WDYT ?
>>>
>>> Regards
>>> JB
>>>
>>> On 07/08/2011 09:56 AM, Guillaume Nodet wrote:
>>>>
>>>> I've been experimenting with a first value added feature for camel routes
>>>> deployed in smx5.
>>>> The idea is to have a profiling strategy similar to a java profiler.
>>>> The output I have in my test is the following:
>>>>
>>>> Processor Count Time Total
>>>> Route[[From[direct:a]] -> [To[mock:p...] 0 0 3536
>>>> To[mock:polyglot] 1000 149 149
>>>> Choice[[When[{org.apache.camel.sca...] 1000 63 3386
>>>> When[{org.apache.camel.scala.Sca...] 1000 2208 2277
>>>> To[mock:english] 328 69 69
>>>> When[{org.apache.camel.scala.Sca...] 672 74 976
>>>> To[mock:dutch] 339 74 74
>>>> Delay[{2} -> []] 339 727 727
>>>> To[mock:german] 339 100 100
>>>> Otherwise[[To[mock:french]]] 333 8 69
>>>> To[mock:french] 333 60 60
>>>>
>>>>
>>>> And the route is defined using the scala DSL as:
>>>>
>>>> context.addRoutes(new RouteBuilder {
>>>> "direct:a" ==> {
>>>> to("mock:polyglot")
>>>> choice {
>>>> when( (e: Exchange) => { sleep(); e.in == "<hello/>" }) {
>>>> to ("mock:english")
>>>> }
>>>> when(_.in == "<hallo/>") {
>>>> to("mock:dutch")
>>>> delay( 2 ms )
>>>> to("mock:german")
>>>> }
>>>> otherwise to ("mock:french")
>>>> }
>>>> }
>>>> });
>>>>
>>>> This currently requires some modifications to camel which I've done
>>>> locally,
>>>> so you won't really be able to experiment with it at this point, but I
>>>> just
>>>> wanted to give a heads up, as I found this feature quite interesting.
>>>>
>>>
>>> --
>>> Jean-Baptiste Onofré
>>> jbonofre@apache.org
>>> http://blog.nanthrax.net
>>> Talend - http://www.talend.com
>>
>>
>>
>> --
>> ------------------------
>> Guillaume Nodet
>> ------------------------
>> Blog: http://gnodet.blogspot.com/
>> ------------------------
>> Open Source SOA
>> http://fusesource.com
>>
>>
>
>
>
> --
> ------------------------
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
Re: [smx5] Scala based (was Re: Profiling stragegy)
Posted by Guillaume Nodet <gn...@gmail.com>.
I think the discussion stopped a few days ago, so I'll try to sum up.
There has been no strong opposition to move to Scala and overall it
would be seen as a good thing. However it may affect users and / or
servicemix developer communities and some concerns have been raised:
* for users, I think there's a consensus to make sure that
developing parts of ServiceMix in scala does not affect downstream
users so that they can't still continue using java.
* for developers: switching to Scala might push some ServiceMix
committers down to learning a new language which would take some time
they may not be ready to spend, and may lower the number of ServiceMix
users who could have contributed to the project and become committers
For the first point, I think this means that any API / SPI would have
to be developed in Java rather than directly in Scala. That would
address most of the problems as the only effect on users would be the
need to have the scala libraries on the classpath or deployed in osgi.
For the second point, I agree that may be slightly more difficult to
address. New features could be developed in Java and contributed, but
for patches, users/developers would have to understand scala a bit.
On Fri, Jul 8, 2011 at 10:12, Guillaume Nodet <gn...@gmail.com> wrote:
> Yeah, definitely. I don't think we've really discussed that point. I used
> scala for the following reasons right now:
> * the manual / web console (almost empty now) are based on scalate which
> is focusing on scala
> * it forces me to learn Scala ;-)
> I agree we need to make sure we all agree on which direction to go.
> I don't have much knowledge of Scala yet so I'm far less productive than
> when using Java right now (I guess a lot of us are newbies too).
> I was going to try finding benefits and list them, but I just came across
> James's blog entry:
> http://macstrac.blogspot.com/2009/04/scala-as-long-term-replacement-for.html
> In short, Scala is just a better language I think. How long will we have to
> wait for java closures? And even when they come, it will be in Java 7 or 8
> which we won't be able to use until a few years.
> Anyway, I know I'll be a little less productive at least for a few months,
> but I think the long term benefits are greater than the cost.
> On Fri, Jul 8, 2011 at 09:59, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
>>
>> Hi Guillaume,
>>
>> thanks a bunch, it looks very good.
>>
>> I see that you implemented in Scala.
>>
>> Does it mean that SMX5 will by Scala based ?
>> We had discussion on the mailing list around that but I didn't see an
>> agreement about that.
>>
>> Maybe, we should start a vote to see if the community is ready to go to
>> Scala for SMX.
>>
>> WDYT ?
>>
>> Regards
>> JB
>>
>> On 07/08/2011 09:56 AM, Guillaume Nodet wrote:
>>>
>>> I've been experimenting with a first value added feature for camel routes
>>> deployed in smx5.
>>> The idea is to have a profiling strategy similar to a java profiler.
>>> The output I have in my test is the following:
>>>
>>> Processor Count Time Total
>>> Route[[From[direct:a]] -> [To[mock:p...] 0 0 3536
>>> To[mock:polyglot] 1000 149 149
>>> Choice[[When[{org.apache.camel.sca...] 1000 63 3386
>>> When[{org.apache.camel.scala.Sca...] 1000 2208 2277
>>> To[mock:english] 328 69 69
>>> When[{org.apache.camel.scala.Sca...] 672 74 976
>>> To[mock:dutch] 339 74 74
>>> Delay[{2} -> []] 339 727 727
>>> To[mock:german] 339 100 100
>>> Otherwise[[To[mock:french]]] 333 8 69
>>> To[mock:french] 333 60 60
>>>
>>>
>>> And the route is defined using the scala DSL as:
>>>
>>> context.addRoutes(new RouteBuilder {
>>> "direct:a" ==> {
>>> to("mock:polyglot")
>>> choice {
>>> when( (e: Exchange) => { sleep(); e.in == "<hello/>" }) {
>>> to ("mock:english")
>>> }
>>> when(_.in == "<hallo/>") {
>>> to("mock:dutch")
>>> delay( 2 ms )
>>> to("mock:german")
>>> }
>>> otherwise to ("mock:french")
>>> }
>>> }
>>> });
>>>
>>> This currently requires some modifications to camel which I've done
>>> locally,
>>> so you won't really be able to experiment with it at this point, but I
>>> just
>>> wanted to give a heads up, as I found this feature quite interesting.
>>>
>>
>> --
>> Jean-Baptiste Onofré
>> jbonofre@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>
>
>
> --
> ------------------------
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
>
--
------------------------
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: [smx5] Scala based (was Re: Profiling stragegy)
Posted by Rob Davies <ra...@gmail.com>.
I share your concerns Charles. More importantly, finding good Scala programmers outside of the current Servicemix contributors, who would be interested in contributing to the project is going to be hard. I'm not sure this plays in the right way of re-invogourating the ServiceMix project.
On 8 Jul 2011, at 11:31, Charles Moulliard wrote:
> You are right except that what we will deploy will be Java bundles
> coming from projects. That means that when debugging will be required,
> that will complicate the process as we have to debug java codes and
> perhaps (this is what we do now under SMX/Karaf) classes of the
> platform itself who will be in Scala (with SMX5). From this
> perspective, our users will be impacted by this choice and some of
> them will be reluctant.
>
> just 2 cents for the discussion.
>
> On Fri, Jul 8, 2011 at 12:19 PM, James Strachan <ja...@fusesource.com> wrote:
>> How would a user/customer know what tools where used to create
>> servicemix 5? So long as its available as jars/bundles and there's a
>> web console, who cares if there's JSP or XSLT or Java or Scala or
>> Scalate or whatever?
>>
>> On 8 July 2011 11:14, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
>>> From a pure technical point of view, it can be very interesting and fun. Of
>>> course, we need some time at the beginning, but it's not a big deal.
>>>
>>> My concern is more for users/customers: I do not want to scare them by
>>> mixing Java/Scala, or going only to Scala which is not really heavily known
>>> in the industry for now.
>>>
>>> As we said in French: "j'ai le cul entre deux chaises" (which can be
>>> translated by "I ass between two chairs" :)).
>>>
>>> I would like more time to send my formal vote :)
>>>
>>> Regards
>>> JB
>>>
>>> On 07/08/2011 10:47 AM, Ioannis Canellos wrote:
>>>>
>>>> I like the idea of using Scala inside ServiceMix for the reason its just a
>>>> better language than Java, which you can use without sacrificing any of
>>>> the
>>>> Java coolness *(in terms of tools frameworks etc)*.
>>>>
>>>> I've only used Scala once, in a tiny web application combined with Apache
>>>> Wicket and I can say that the result was great as the boilerplate was
>>>> significantly reduced.
>>>>
>>>> I am definitely no expert, but I'd love to use Scala in ServiceMix5.
>>>>
>>>
>>> --
>>> Jean-Baptiste Onofré
>>> jbonofre@apache.org
>>> http://blog.nanthrax.net
>>> Talend - http://www.talend.com
>>>
>>
>>
>>
>> --
>> James
>> -------
>> FuseSource
>> Email: james@fusesource.com
>> Web: http://fusesource.com
>> Twitter: jstrachan, fusenews
>> Blog: http://macstrac.blogspot.com/
>>
>> Open Source Integration and Messaging
>>
Re: [smx5] Scala based (was Re: Profiling stragegy)
Posted by James Strachan <ja...@fusesource.com>.
You'd need a Scala IDE (IDEA / Eclipse + Scala plugin) but debugging
works fine - so long as you've the source or map to where the source
is.
On 8 July 2011 11:31, Charles Moulliard <cm...@gmail.com> wrote:
> You are right except that what we will deploy will be Java bundles
> coming from projects. That means that when debugging will be required,
> that will complicate the process as we have to debug java codes and
> perhaps (this is what we do now under SMX/Karaf) classes of the
> platform itself who will be in Scala (with SMX5). From this
> perspective, our users will be impacted by this choice and some of
> them will be reluctant.
>
> just 2 cents for the discussion.
>
> On Fri, Jul 8, 2011 at 12:19 PM, James Strachan <ja...@fusesource.com> wrote:
>> How would a user/customer know what tools where used to create
>> servicemix 5? So long as its available as jars/bundles and there's a
>> web console, who cares if there's JSP or XSLT or Java or Scala or
>> Scalate or whatever?
>>
>> On 8 July 2011 11:14, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
>>> From a pure technical point of view, it can be very interesting and fun. Of
>>> course, we need some time at the beginning, but it's not a big deal.
>>>
>>> My concern is more for users/customers: I do not want to scare them by
>>> mixing Java/Scala, or going only to Scala which is not really heavily known
>>> in the industry for now.
>>>
>>> As we said in French: "j'ai le cul entre deux chaises" (which can be
>>> translated by "I ass between two chairs" :)).
>>>
>>> I would like more time to send my formal vote :)
>>>
>>> Regards
>>> JB
>>>
>>> On 07/08/2011 10:47 AM, Ioannis Canellos wrote:
>>>>
>>>> I like the idea of using Scala inside ServiceMix for the reason its just a
>>>> better language than Java, which you can use without sacrificing any of
>>>> the
>>>> Java coolness *(in terms of tools frameworks etc)*.
>>>>
>>>> I've only used Scala once, in a tiny web application combined with Apache
>>>> Wicket and I can say that the result was great as the boilerplate was
>>>> significantly reduced.
>>>>
>>>> I am definitely no expert, but I'd love to use Scala in ServiceMix5.
>>>>
>>>
>>> --
>>> Jean-Baptiste Onofré
>>> jbonofre@apache.org
>>> http://blog.nanthrax.net
>>> Talend - http://www.talend.com
>>>
>>
>>
>>
>> --
>> James
>> -------
>> FuseSource
>> Email: james@fusesource.com
>> Web: http://fusesource.com
>> Twitter: jstrachan, fusenews
>> Blog: http://macstrac.blogspot.com/
>>
>> Open Source Integration and Messaging
>>
>
--
James
-------
FuseSource
Email: james@fusesource.com
Web: http://fusesource.com
Twitter: jstrachan, fusenews
Blog: http://macstrac.blogspot.com/
Open Source Integration and Messaging
Re: [smx5] Scala based (was Re: Profiling stragegy)
Posted by Charles Moulliard <cm...@gmail.com>.
You are right except that what we will deploy will be Java bundles
coming from projects. That means that when debugging will be required,
that will complicate the process as we have to debug java codes and
perhaps (this is what we do now under SMX/Karaf) classes of the
platform itself who will be in Scala (with SMX5). From this
perspective, our users will be impacted by this choice and some of
them will be reluctant.
just 2 cents for the discussion.
On Fri, Jul 8, 2011 at 12:19 PM, James Strachan <ja...@fusesource.com> wrote:
> How would a user/customer know what tools where used to create
> servicemix 5? So long as its available as jars/bundles and there's a
> web console, who cares if there's JSP or XSLT or Java or Scala or
> Scalate or whatever?
>
> On 8 July 2011 11:14, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
>> From a pure technical point of view, it can be very interesting and fun. Of
>> course, we need some time at the beginning, but it's not a big deal.
>>
>> My concern is more for users/customers: I do not want to scare them by
>> mixing Java/Scala, or going only to Scala which is not really heavily known
>> in the industry for now.
>>
>> As we said in French: "j'ai le cul entre deux chaises" (which can be
>> translated by "I ass between two chairs" :)).
>>
>> I would like more time to send my formal vote :)
>>
>> Regards
>> JB
>>
>> On 07/08/2011 10:47 AM, Ioannis Canellos wrote:
>>>
>>> I like the idea of using Scala inside ServiceMix for the reason its just a
>>> better language than Java, which you can use without sacrificing any of
>>> the
>>> Java coolness *(in terms of tools frameworks etc)*.
>>>
>>> I've only used Scala once, in a tiny web application combined with Apache
>>> Wicket and I can say that the result was great as the boilerplate was
>>> significantly reduced.
>>>
>>> I am definitely no expert, but I'd love to use Scala in ServiceMix5.
>>>
>>
>> --
>> Jean-Baptiste Onofré
>> jbonofre@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
>
>
>
> --
> James
> -------
> FuseSource
> Email: james@fusesource.com
> Web: http://fusesource.com
> Twitter: jstrachan, fusenews
> Blog: http://macstrac.blogspot.com/
>
> Open Source Integration and Messaging
>
Re: [smx5] Scala based (was Re: Profiling stragegy)
Posted by Michael Van <mv...@comcast.net>.
+1
Moving some bits of SMX to Scala is a great idea. Before moving, we should:
1) Ensure we are only using Scala where it makes sense. No need to re-invent
(read re-write) packages in Scala simply because Scala is sexy.
2) Ensure we have a good FAQ or tutorial explaining how to set up your ide
(IntelliJ and Eclipse) to use Scala, and then how to build SMX 5.0.
Jean-Baptiste Onofré wrote:
>
> Thanks for the update James.
>
> It's more clear :)
>
> Regards
> JB
>
> On 07/08/2011 01:27 PM, James Strachan wrote:
>> On 8 July 2011 11:29, Jean-Baptiste Onofré<jb@nanthrax.net> wrote:
>>> James,
>>>
>>> I found this blog:
>>> http://kotek.net/blog/scala_problems
>>>
>>> WDYT ?
>>
>> Most of the issues are old (e.g. old versions of scala kept breaking
>> bytecode compatibility, something OSGi can help you with anyway) or
>> tooling issues. See the comments - e.g. use SBT / FSC option in your
>> IDE. I use IDEA with Scala with FST on and its pretty fast and snappy.
>>
>> Using SBT in incremental compile/test mode on 0.10 is now *much
>> faster* than using maven and java :). As you change a line of code in
>> your IDE everything recompiles& reruns really quickly.
>>
>>
>>> Especially around the size of the jar.
>>>
>>> Doesn't it in "opposition" with the OSGi granularity ?
>>
>> Am not really sure if the exact size of a jar file is much of a
>> concern in the grand scheme of things; it certainly doesn't affect
>> granularity at least. That being said, sure Scala uses more classes in
>> the generated bytecode (as does Java 8's closures& java 4's inner
>> classes), but then the Scala library replaces a ton of boilerplate
>> bytecode operations you have to do in Java for doing
>> loops/mapping/transforming/filtering of code so its probably a case
>> that you use much less actual code and less helper classes (often
>> copied randomly from project to project) and libraries (google
>> collections v common collections v guava v all the other java
>> libraries attempting to make collections more palatable in Java).
>>
>> Though if you're ever worried about jar sizes for Scala or Java,
>> there's always ProGuard to trim dead code.
>>
>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
--
View this message in context: http://servicemix.396122.n5.nabble.com/smx5-Scala-based-was-Re-Profiling-stragegy-tp4563861p4564747.html
Sent from the ServiceMix - Dev mailing list archive at Nabble.com.
Re: [smx5] Scala based (was Re: Profiling stragegy)
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Thanks for the update James.
It's more clear :)
Regards
JB
On 07/08/2011 01:27 PM, James Strachan wrote:
> On 8 July 2011 11:29, Jean-Baptiste Onofré<jb...@nanthrax.net> wrote:
>> James,
>>
>> I found this blog:
>> http://kotek.net/blog/scala_problems
>>
>> WDYT ?
>
> Most of the issues are old (e.g. old versions of scala kept breaking
> bytecode compatibility, something OSGi can help you with anyway) or
> tooling issues. See the comments - e.g. use SBT / FSC option in your
> IDE. I use IDEA with Scala with FST on and its pretty fast and snappy.
>
> Using SBT in incremental compile/test mode on 0.10 is now *much
> faster* than using maven and java :). As you change a line of code in
> your IDE everything recompiles& reruns really quickly.
>
>
>> Especially around the size of the jar.
>>
>> Doesn't it in "opposition" with the OSGi granularity ?
>
> Am not really sure if the exact size of a jar file is much of a
> concern in the grand scheme of things; it certainly doesn't affect
> granularity at least. That being said, sure Scala uses more classes in
> the generated bytecode (as does Java 8's closures& java 4's inner
> classes), but then the Scala library replaces a ton of boilerplate
> bytecode operations you have to do in Java for doing
> loops/mapping/transforming/filtering of code so its probably a case
> that you use much less actual code and less helper classes (often
> copied randomly from project to project) and libraries (google
> collections v common collections v guava v all the other java
> libraries attempting to make collections more palatable in Java).
>
> Though if you're ever worried about jar sizes for Scala or Java,
> there's always ProGuard to trim dead code.
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: [smx5] Scala based (was Re: Profiling stragegy)
Posted by James Strachan <ja...@fusesource.com>.
On 8 July 2011 11:29, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
> James,
>
> I found this blog:
> http://kotek.net/blog/scala_problems
>
> WDYT ?
Most of the issues are old (e.g. old versions of scala kept breaking
bytecode compatibility, something OSGi can help you with anyway) or
tooling issues. See the comments - e.g. use SBT / FSC option in your
IDE. I use IDEA with Scala with FST on and its pretty fast and snappy.
Using SBT in incremental compile/test mode on 0.10 is now *much
faster* than using maven and java :). As you change a line of code in
your IDE everything recompiles & reruns really quickly.
> Especially around the size of the jar.
>
> Doesn't it in "opposition" with the OSGi granularity ?
Am not really sure if the exact size of a jar file is much of a
concern in the grand scheme of things; it certainly doesn't affect
granularity at least. That being said, sure Scala uses more classes in
the generated bytecode (as does Java 8's closures & java 4's inner
classes), but then the Scala library replaces a ton of boilerplate
bytecode operations you have to do in Java for doing
loops/mapping/transforming/filtering of code so its probably a case
that you use much less actual code and less helper classes (often
copied randomly from project to project) and libraries (google
collections v common collections v guava v all the other java
libraries attempting to make collections more palatable in Java).
Though if you're ever worried about jar sizes for Scala or Java,
there's always ProGuard to trim dead code.
--
James
-------
FuseSource
Email: james@fusesource.com
Web: http://fusesource.com
Twitter: jstrachan, fusenews
Blog: http://macstrac.blogspot.com/
Open Source Integration and Messaging
Re: [smx5] Scala based (was Re: Profiling stragegy)
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
James,
I found this blog:
http://kotek.net/blog/scala_problems
WDYT ?
Especially around the size of the jar.
Doesn't it in "opposition" with the OSGi granularity ?
Regards
JB
On 07/08/2011 12:19 PM, James Strachan wrote:
> How would a user/customer know what tools where used to create
> servicemix 5? So long as its available as jars/bundles and there's a
> web console, who cares if there's JSP or XSLT or Java or Scala or
> Scalate or whatever?
>
> On 8 July 2011 11:14, Jean-Baptiste Onofré<jb...@nanthrax.net> wrote:
>> From a pure technical point of view, it can be very interesting and fun. Of
>> course, we need some time at the beginning, but it's not a big deal.
>>
>> My concern is more for users/customers: I do not want to scare them by
>> mixing Java/Scala, or going only to Scala which is not really heavily known
>> in the industry for now.
>>
>> As we said in French: "j'ai le cul entre deux chaises" (which can be
>> translated by "I ass between two chairs" :)).
>>
>> I would like more time to send my formal vote :)
>>
>> Regards
>> JB
>>
>> On 07/08/2011 10:47 AM, Ioannis Canellos wrote:
>>>
>>> I like the idea of using Scala inside ServiceMix for the reason its just a
>>> better language than Java, which you can use without sacrificing any of
>>> the
>>> Java coolness *(in terms of tools frameworks etc)*.
>>>
>>> I've only used Scala once, in a tiny web application combined with Apache
>>> Wicket and I can say that the result was great as the boilerplate was
>>> significantly reduced.
>>>
>>> I am definitely no expert, but I'd love to use Scala in ServiceMix5.
>>>
>>
>> --
>> Jean-Baptiste Onofré
>> jbonofre@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
>
>
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: [smx5] Scala based (was Re: Profiling stragegy)
Posted by James Strachan <ja...@fusesource.com>.
+1 for everyone exposing their concerns, thanks JB :)
On 8 July 2011 11:22, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
> +1 James
>
> I just try to expose the thoughts that come in my mind :)
> Just to share together and list to pros/cons.
>
> Thanks
> Regards
> JB
>
> On 07/08/2011 12:19 PM, James Strachan wrote:
>>
>> How would a user/customer know what tools where used to create
>> servicemix 5? So long as its available as jars/bundles and there's a
>> web console, who cares if there's JSP or XSLT or Java or Scala or
>> Scalate or whatever?
>>
>> On 8 July 2011 11:14, Jean-Baptiste Onofré<jb...@nanthrax.net> wrote:
>>>
>>> From a pure technical point of view, it can be very interesting and fun.
>>> Of
>>> course, we need some time at the beginning, but it's not a big deal.
>>>
>>> My concern is more for users/customers: I do not want to scare them by
>>> mixing Java/Scala, or going only to Scala which is not really heavily
>>> known
>>> in the industry for now.
>>>
>>> As we said in French: "j'ai le cul entre deux chaises" (which can be
>>> translated by "I ass between two chairs" :)).
>>>
>>> I would like more time to send my formal vote :)
>>>
>>> Regards
>>> JB
>>>
>>> On 07/08/2011 10:47 AM, Ioannis Canellos wrote:
>>>>
>>>> I like the idea of using Scala inside ServiceMix for the reason its just
>>>> a
>>>> better language than Java, which you can use without sacrificing any of
>>>> the
>>>> Java coolness *(in terms of tools frameworks etc)*.
>>>>
>>>> I've only used Scala once, in a tiny web application combined with
>>>> Apache
>>>> Wicket and I can say that the result was great as the boilerplate was
>>>> significantly reduced.
>>>>
>>>> I am definitely no expert, but I'd love to use Scala in ServiceMix5.
>>>>
>>>
>>> --
>>> Jean-Baptiste Onofré
>>> jbonofre@apache.org
>>> http://blog.nanthrax.net
>>> Talend - http://www.talend.com
>>>
>>
>>
>>
>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
--
James
-------
FuseSource
Email: james@fusesource.com
Web: http://fusesource.com
Twitter: jstrachan, fusenews
Blog: http://macstrac.blogspot.com/
Open Source Integration and Messaging
Re: [smx5] Scala based (was Re: Profiling stragegy)
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
+1 James
I just try to expose the thoughts that come in my mind :)
Just to share together and list to pros/cons.
Thanks
Regards
JB
On 07/08/2011 12:19 PM, James Strachan wrote:
> How would a user/customer know what tools where used to create
> servicemix 5? So long as its available as jars/bundles and there's a
> web console, who cares if there's JSP or XSLT or Java or Scala or
> Scalate or whatever?
>
> On 8 July 2011 11:14, Jean-Baptiste Onofré<jb...@nanthrax.net> wrote:
>> From a pure technical point of view, it can be very interesting and fun. Of
>> course, we need some time at the beginning, but it's not a big deal.
>>
>> My concern is more for users/customers: I do not want to scare them by
>> mixing Java/Scala, or going only to Scala which is not really heavily known
>> in the industry for now.
>>
>> As we said in French: "j'ai le cul entre deux chaises" (which can be
>> translated by "I ass between two chairs" :)).
>>
>> I would like more time to send my formal vote :)
>>
>> Regards
>> JB
>>
>> On 07/08/2011 10:47 AM, Ioannis Canellos wrote:
>>>
>>> I like the idea of using Scala inside ServiceMix for the reason its just a
>>> better language than Java, which you can use without sacrificing any of
>>> the
>>> Java coolness *(in terms of tools frameworks etc)*.
>>>
>>> I've only used Scala once, in a tiny web application combined with Apache
>>> Wicket and I can say that the result was great as the boilerplate was
>>> significantly reduced.
>>>
>>> I am definitely no expert, but I'd love to use Scala in ServiceMix5.
>>>
>>
>> --
>> Jean-Baptiste Onofré
>> jbonofre@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
>
>
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: [smx5] Scala based (was Re: Profiling stragegy)
Posted by Claus Ibsen <cl...@gmail.com>.
Have some pieces that are Scala could in fact attract new great
contributors/committers to the project.
If we keep using the good old dusty Java then the new generations of
great minds may not be so reluctant to start contributing.
However when using Scala we should bite this piece by piece.
And try to avoid adding to advanced code from the very start, so the
less trained eye do have a clue whats going on.
On Fri, Jul 8, 2011 at 12:23 PM, James Strachan <ja...@fusesource.com> wrote:
> To be a little more clear - the only risk from a user perspective of
> using Scala is not having nice Java APIs for Java developers to use.
> But as HawtDispatch & Akka have shown; its easy to have great Java and
> Scala APIs to frameworks.
>
> However for implementation stuff, users wouldn't really know how the
> Java bytecode was created unless they decompiled it or grep'd your
> source code :). Its all just java bytecode in jars/bundles/wars.
>
> On 8 July 2011 11:19, James Strachan <ja...@fusesource.com> wrote:
>> How would a user/customer know what tools where used to create
>> servicemix 5? So long as its available as jars/bundles and there's a
>> web console, who cares if there's JSP or XSLT or Java or Scala or
>> Scalate or whatever?
>>
>> On 8 July 2011 11:14, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
>>> From a pure technical point of view, it can be very interesting and fun. Of
>>> course, we need some time at the beginning, but it's not a big deal.
>>>
>>> My concern is more for users/customers: I do not want to scare them by
>>> mixing Java/Scala, or going only to Scala which is not really heavily known
>>> in the industry for now.
>>>
>>> As we said in French: "j'ai le cul entre deux chaises" (which can be
>>> translated by "I ass between two chairs" :)).
>>>
>>> I would like more time to send my formal vote :)
>>>
>>> Regards
>>> JB
>>>
>>> On 07/08/2011 10:47 AM, Ioannis Canellos wrote:
>>>>
>>>> I like the idea of using Scala inside ServiceMix for the reason its just a
>>>> better language than Java, which you can use without sacrificing any of
>>>> the
>>>> Java coolness *(in terms of tools frameworks etc)*.
>>>>
>>>> I've only used Scala once, in a tiny web application combined with Apache
>>>> Wicket and I can say that the result was great as the boilerplate was
>>>> significantly reduced.
>>>>
>>>> I am definitely no expert, but I'd love to use Scala in ServiceMix5.
>>>>
>>>
>>> --
>>> Jean-Baptiste Onofré
>>> jbonofre@apache.org
>>> http://blog.nanthrax.net
>>> Talend - http://www.talend.com
>>>
>>
>>
>>
>> --
>> James
>> -------
>> FuseSource
>> Email: james@fusesource.com
>> Web: http://fusesource.com
>> Twitter: jstrachan, fusenews
>> Blog: http://macstrac.blogspot.com/
>>
>> Open Source Integration and Messaging
>>
>
>
>
> --
> James
> -------
> FuseSource
> Email: james@fusesource.com
> Web: http://fusesource.com
> Twitter: jstrachan, fusenews
> Blog: http://macstrac.blogspot.com/
>
> Open Source Integration and Messaging
>
--
Claus Ibsen
-----------------
FuseSource
Email: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/
Re: [smx5] Scala based (was Re: Profiling stragegy)
Posted by James Strachan <ja...@fusesource.com>.
To be a little more clear - the only risk from a user perspective of
using Scala is not having nice Java APIs for Java developers to use.
But as HawtDispatch & Akka have shown; its easy to have great Java and
Scala APIs to frameworks.
However for implementation stuff, users wouldn't really know how the
Java bytecode was created unless they decompiled it or grep'd your
source code :). Its all just java bytecode in jars/bundles/wars.
On 8 July 2011 11:19, James Strachan <ja...@fusesource.com> wrote:
> How would a user/customer know what tools where used to create
> servicemix 5? So long as its available as jars/bundles and there's a
> web console, who cares if there's JSP or XSLT or Java or Scala or
> Scalate or whatever?
>
> On 8 July 2011 11:14, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
>> From a pure technical point of view, it can be very interesting and fun. Of
>> course, we need some time at the beginning, but it's not a big deal.
>>
>> My concern is more for users/customers: I do not want to scare them by
>> mixing Java/Scala, or going only to Scala which is not really heavily known
>> in the industry for now.
>>
>> As we said in French: "j'ai le cul entre deux chaises" (which can be
>> translated by "I ass between two chairs" :)).
>>
>> I would like more time to send my formal vote :)
>>
>> Regards
>> JB
>>
>> On 07/08/2011 10:47 AM, Ioannis Canellos wrote:
>>>
>>> I like the idea of using Scala inside ServiceMix for the reason its just a
>>> better language than Java, which you can use without sacrificing any of
>>> the
>>> Java coolness *(in terms of tools frameworks etc)*.
>>>
>>> I've only used Scala once, in a tiny web application combined with Apache
>>> Wicket and I can say that the result was great as the boilerplate was
>>> significantly reduced.
>>>
>>> I am definitely no expert, but I'd love to use Scala in ServiceMix5.
>>>
>>
>> --
>> Jean-Baptiste Onofré
>> jbonofre@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
>
>
>
> --
> James
> -------
> FuseSource
> Email: james@fusesource.com
> Web: http://fusesource.com
> Twitter: jstrachan, fusenews
> Blog: http://macstrac.blogspot.com/
>
> Open Source Integration and Messaging
>
--
James
-------
FuseSource
Email: james@fusesource.com
Web: http://fusesource.com
Twitter: jstrachan, fusenews
Blog: http://macstrac.blogspot.com/
Open Source Integration and Messaging
Re: [smx5] Scala based (was Re: Profiling stragegy)
Posted by James Strachan <ja...@fusesource.com>.
How would a user/customer know what tools where used to create
servicemix 5? So long as its available as jars/bundles and there's a
web console, who cares if there's JSP or XSLT or Java or Scala or
Scalate or whatever?
On 8 July 2011 11:14, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
> From a pure technical point of view, it can be very interesting and fun. Of
> course, we need some time at the beginning, but it's not a big deal.
>
> My concern is more for users/customers: I do not want to scare them by
> mixing Java/Scala, or going only to Scala which is not really heavily known
> in the industry for now.
>
> As we said in French: "j'ai le cul entre deux chaises" (which can be
> translated by "I ass between two chairs" :)).
>
> I would like more time to send my formal vote :)
>
> Regards
> JB
>
> On 07/08/2011 10:47 AM, Ioannis Canellos wrote:
>>
>> I like the idea of using Scala inside ServiceMix for the reason its just a
>> better language than Java, which you can use without sacrificing any of
>> the
>> Java coolness *(in terms of tools frameworks etc)*.
>>
>> I've only used Scala once, in a tiny web application combined with Apache
>> Wicket and I can say that the result was great as the boilerplate was
>> significantly reduced.
>>
>> I am definitely no expert, but I'd love to use Scala in ServiceMix5.
>>
>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
--
James
-------
FuseSource
Email: james@fusesource.com
Web: http://fusesource.com
Twitter: jstrachan, fusenews
Blog: http://macstrac.blogspot.com/
Open Source Integration and Messaging
Re: [smx5] Scala based (was Re: Profiling stragegy)
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
From a pure technical point of view, it can be very interesting and
fun. Of course, we need some time at the beginning, but it's not a big deal.
My concern is more for users/customers: I do not want to scare them by
mixing Java/Scala, or going only to Scala which is not really heavily
known in the industry for now.
As we said in French: "j'ai le cul entre deux chaises" (which can be
translated by "I ass between two chairs" :)).
I would like more time to send my formal vote :)
Regards
JB
On 07/08/2011 10:47 AM, Ioannis Canellos wrote:
> I like the idea of using Scala inside ServiceMix for the reason its just a
> better language than Java, which you can use without sacrificing any of the
> Java coolness *(in terms of tools frameworks etc)*.
>
> I've only used Scala once, in a tiny web application combined with Apache
> Wicket and I can say that the result was great as the boilerplate was
> significantly reduced.
>
> I am definitely no expert, but I'd love to use Scala in ServiceMix5.
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: [smx5] Scala based (was Re: Profiling stragegy)
Posted by Ioannis Canellos <io...@gmail.com>.
I like the idea of using Scala inside ServiceMix for the reason its just a
better language than Java, which you can use without sacrificing any of the
Java coolness *(in terms of tools frameworks etc)*.
I've only used Scala once, in a tiny web application combined with Apache
Wicket and I can say that the result was great as the boilerplate was
significantly reduced.
I am definitely no expert, but I'd love to use Scala in ServiceMix5.
--
*Ioannis Canellos*
*
http://iocanel.blogspot.com
Apache Karaf <http://karaf.apache.org/> Committer & PMC
Apache ServiceMix <http://servicemix.apache.org/> Committer
*