You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@camel.apache.org by Vadim Chekan <vc...@cox.net> on 2008/11/03 10:04:30 UTC
Re: Thoughs on the camel dsl for 2.x
Hi Hadrian,
I agree with you that configuring a route of moderate complexity is not
as easy as we would like it to be.
I've created CAMEL-1046 and attached what I have so far.
Here is my vision of the language:
https://issues.apache.org/activemq/secure/attachment/17204/test.txt
I'm still tweaking the syntax to make it more consistent and to follow
the principle of the least surprise. And a lot of features still have
not made it to the language.
I've created a folder camel-dsl but maven is an unknown animal to me so
the folder lacks proper structure and is not hooked up to the project.
Could somebody explain the page:
http://activemq.apache.org/camel/creating-a-new-spring-based-camel-route.html
What should be archetypeArtifactId; groupId; artifactId?
Vadim.
Hadrian Zbarcea wrote:
> Camel has this wonderful discovery mechanism for RouteBuilders,
> TypeConverters, Languages, etc. so if one uses Camel she only needs to
> write her code, drop it somewhere on the classpath and... everything works.
>
> The only main thing that's not really pluggable is the DSL. The concept
> of a DSL supported for multiple languages is unique to Camel afaik and
> quite a powerful one. However:
> * it is hand-crafted and this led to quite a few inconsistencies between
> java, xml, scala, etc.
> * the dsl is not supported in a few languages yet, such as python, ruby
> (expressions are supported though)
> * the ProcessorType has become huge
> * it's increasingly difficult/annoying to add support for a new pattern,
> because this changes the API
> * does not support user-defined pattern, a user is pretty much stuck
> with using a processor or bean, but cannot extend the language
> * does not support alternate dsl(s) in the same language, such as java.
> The processors are very powerful, and one could envision using a
> different language (say something like bpel), to assemble them and get
> the desired behavior.
>
>
> I think the biggest hurdle is I think the fact that we must support
> smart completion in the ide(s) and java is not a dynamic language. I
> would like to investigate the idea of patterns being *described* in a
> language (such as xml, or some other grammar) and then generate the
> dsl. I think it should be feasible, based on the fact that there are
> not many concepts needed to describe a pattern (as a black box) and the
> generated dsl could be built once (maybe packaged as a separate jar) and
> reused.
>
> Your thoughts highly appreciated.
> Hadrian
>
Re: Thoughs on the camel dsl for 2.x
Posted by James Strachan <ja...@gmail.com>.
2008/11/3 Hadrian Zbarcea <hz...@gmail.com>:
> Vadim,
>
> Awsome work.
>
> Given the popularity of maven and the fact that we (and others) use it
> intensively, I think it's time well spent to get to know it in more details.
> Here's an excellent resource:
> http://maven.apache.org/articles.html
>
> For the dsl solution I personally have to candidates. I didn't mention them
> before, because I was curious what other people ideas were.
>
> One is what James suggested (on a previous occasion too). Take the model in
> org.apache.camel.model and use it as the AST (Abstract Syntax Tree). It's
> not as simple as it sounds (except for James :) ).
>
> The second is using a grammar and antlr, and I played with that a while ago
> and got stuck in a circular dependency.
The two could well be the same thing BTW. i.e. use an Antlr grammar
which when its run it creates an AST which either can be directly
turned into the Camel AST (org.apache.camel.model.*) or indirectly via
a little AST visitor thingy
--
James
-------
http://macstrac.blogspot.com/
Open Source Integration
http://fusesource.com/
Re: Thoughs on the camel dsl for 2.x
Posted by Hadrian Zbarcea <hz...@gmail.com>.
Vadim,
Awsome work.
Given the popularity of maven and the fact that we (and others) use it
intensively, I think it's time well spent to get to know it in more
details. Here's an excellent resource:
http://maven.apache.org/articles.html
For the dsl solution I personally have to candidates. I didn't
mention them before, because I was curious what other people ideas were.
One is what James suggested (on a previous occasion too). Take the
model in org.apache.camel.model and use it as the AST (Abstract Syntax
Tree). It's not as simple as it sounds (except for James :) ).
The second is using a grammar and antlr, and I played with that a
while ago and got stuck in a circular dependency.
Ideally we'd be able to model everything in terms of patterns/
processors. The big issue I hit (i both cases) is that what a
pipeline is, is not really know, it's dependent on the number of
patterns (process) currently described in the system. I uses a
separate grammar file for each pattern, you put them all in the same
file. It almost looks to me that the pipeline grammar should not be
hand-written, but generated. Not sure what would work best.
Cheers
Hadrian
On Nov 3, 2008, at 4:04 AM, Vadim Chekan wrote:
> Hi Hadrian,
>
> I agree with you that configuring a route of moderate complexity is
> not as easy as we would like it to be.
>
> I've created CAMEL-1046 and attached what I have so far.
> Here is my vision of the language:
> https://issues.apache.org/activemq/secure/attachment/17204/test.txt
> I'm still tweaking the syntax to make it more consistent and to
> follow the principle of the least surprise. And a lot of features
> still have not made it to the language.
>
> I've created a folder camel-dsl but maven is an unknown animal to me
> so the folder lacks proper structure and is not hooked up to the
> project. Could somebody explain the page:
> http://activemq.apache.org/camel/creating-a-new-spring-based-camel-route.html
> What should be archetypeArtifactId; groupId; artifactId?
>
> Vadim.
>
>
> Hadrian Zbarcea wrote:
>> Camel has this wonderful discovery mechanism for RouteBuilders,
>> TypeConverters, Languages, etc. so if one uses Camel she only needs
>> to write her code, drop it somewhere on the classpath and...
>> everything works.
>> The only main thing that's not really pluggable is the DSL. The
>> concept of a DSL supported for multiple languages is unique to
>> Camel afaik and quite a powerful one. However:
>> * it is hand-crafted and this led to quite a few inconsistencies
>> between java, xml, scala, etc.
>> * the dsl is not supported in a few languages yet, such as python,
>> ruby (expressions are supported though)
>> * the ProcessorType has become huge
>> * it's increasingly difficult/annoying to add support for a new
>> pattern, because this changes the API
>> * does not support user-defined pattern, a user is pretty much
>> stuck with using a processor or bean, but cannot extend the language
>> * does not support alternate dsl(s) in the same language, such as
>> java. The processors are very powerful, and one could envision
>> using a different language (say something like bpel), to assemble
>> them and get the desired behavior.
>> I think the biggest hurdle is I think the fact that we must support
>> smart completion in the ide(s) and java is not a dynamic language.
>> I would like to investigate the idea of patterns being *described*
>> in a language (such as xml, or some other grammar) and then
>> generate the dsl. I think it should be feasible, based on the fact
>> that there are not many concepts needed to describe a pattern (as a
>> black box) and the generated dsl could be built once (maybe
>> packaged as a separate jar) and reused.
>> Your thoughts highly appreciated.
>> Hadrian
>
Re: Thoughs on the camel dsl for 2.x
Posted by Oisin Hurley <oi...@gmail.com>.
On Mon, Nov 3, 2008 at 5:19 PM, James Strachan <ja...@gmail.com> wrote:
> Awesome stuff Oisin! Gonna have a play!
Ping me if the instructions are off, I was reconstructing from memory
a bit (ahem).
--oh
Re: Thoughs on the camel dsl for 2.x
Posted by James Strachan <ja...@gmail.com>.
Awesome stuff Oisin! Gonna have a play!
2008/11/3 Oisin Hurley <oi...@gmail.com>:
> On the subject of smart completion in IDEs, I've been experimenting with the
> Xtext (http://wiki.eclipse.org/Xtext) to produce a simple, text-based
> editor with
> primitive syntax completion, error checking and outline views for Eclipse.
>
> http://code.google.com/p/camel-extra/wiki/CamelSpit
>
> There's some screenshots there to have a look at -- I started by looking at
> Vadim's ANTLR grammar, but drifted from that somewhat purely because I
> haven't fully grokked yet how Xtext does its thing.
>
> Camel processors seem to follow a basic genetic plan, with some semantic
> constraints, along the lines of
>
> <processortype> <expression>
> <action-section>
> <targeting-expression>
> <configuration-section>
>
> plus any scoping syntax to clump things accurately. This could lead to a
> very clear grammar *but* it means that you have extra semantic-check
> pieces to put in to make up for the generic structure (i.e. for some processors
> you don't have configuration, or you can do any actions).
>
> Taking the from the editor perspective, the goals are really to be as
> deterministic
> as possible, so that when a syntax completion request comes in, the options
> that are presented to the developer make sense. Ideally, the semantic processing
> is minimized to cut down on the lag time before the completion pop-up occurs.
>
> The xtext grammar at http://tinyurl.com/5vsp28 goes down this route.
>
> Of course, the bit that's interesting is the approach of going
> editor-first. Xtext
> will generate an ANTLR grammar, as well as the model elements for a syntax
> aware editor and outline view, which is nice. However, the generated ANTLR
> isn't as, ah, elegant as you might want it to be. There's bound to some kind of
> maintenance issue going on there, as well as concerns not being correctly
> separated. Trade-offs persist.
>
> --oh
>
--
James
-------
http://macstrac.blogspot.com/
Open Source Integration
http://fusesource.com/
Re: Thoughs on the camel dsl for 2.x
Posted by Oisin Hurley <oi...@gmail.com>.
On the subject of smart completion in IDEs, I've been experimenting with the
Xtext (http://wiki.eclipse.org/Xtext) to produce a simple, text-based
editor with
primitive syntax completion, error checking and outline views for Eclipse.
http://code.google.com/p/camel-extra/wiki/CamelSpit
There's some screenshots there to have a look at -- I started by looking at
Vadim's ANTLR grammar, but drifted from that somewhat purely because I
haven't fully grokked yet how Xtext does its thing.
Camel processors seem to follow a basic genetic plan, with some semantic
constraints, along the lines of
<processortype> <expression>
<action-section>
<targeting-expression>
<configuration-section>
plus any scoping syntax to clump things accurately. This could lead to a
very clear grammar *but* it means that you have extra semantic-check
pieces to put in to make up for the generic structure (i.e. for some processors
you don't have configuration, or you can do any actions).
Taking the from the editor perspective, the goals are really to be as
deterministic
as possible, so that when a syntax completion request comes in, the options
that are presented to the developer make sense. Ideally, the semantic processing
is minimized to cut down on the lag time before the completion pop-up occurs.
The xtext grammar at http://tinyurl.com/5vsp28 goes down this route.
Of course, the bit that's interesting is the approach of going
editor-first. Xtext
will generate an ANTLR grammar, as well as the model elements for a syntax
aware editor and outline view, which is nice. However, the generated ANTLR
isn't as, ah, elegant as you might want it to be. There's bound to some kind of
maintenance issue going on there, as well as concerns not being correctly
separated. Trade-offs persist.
--oh