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
