It could be handy if we leverage the other lib in the other
camel-module. If the user need the module, it will not be a burden for
him to include a third part lib.
On 8/29/11 8:19 PM, Claus Ibsen wrote:
On Mon, Aug 29, 2011 at 11:14 AM, Christian Schneider
<ch...@die-schneider.net> wrote:
Hi Claus,
the parser looks quite good as far as I looked into it. In any case much
better than regex. Before we replace the old parser we should also think
about tooling though. Some longer time ago I thought about using Xtext for
the camel DSL and also the languages. The advantage would be that it is
quite easy to build real good Editor for the IDE. I guess with the aproach
you followed this is not so easy. Of ocurse the initial effort of Xtext
would be a lot higher but perhaps it can pay off in the long run.
Christian
I wanted something that was simple ;). Well in the sense that it does
not add any extra JARs to the runtime.
So if the tooling can generate plain java source code, then that would be nice.
Also the tooling should be active maintained, so we dont end up using
a dead end project in camel-core.
Another goal is that anyone would be able to understand plain java
code, and with a little reading of the code,
be able to contribute and, eg. add a new function, or operator etc.
I understand that XText is part of Eclipse, and it seems that it uses
ANTLR under the covers.
I would like to not go down a road to add any runtime deps to camel-core.
At camel-extra there is a very old xtext project
http://code.google.com/a/apache-extras.org/p/camel-extra/wiki/CamelSpit
That said, we could possible add some grammar file to camel-core,
which describes the grammer.
Then any 3rd party tooling can use the grammar file to generate a
parser for its tooling.
Am 29.08.2011 10:18, schrieb Claus Ibsen:
Hi
The current Simple language in camel-core has reached its potential in
terms of maintenance and how easy it would be, for example to add new
functions and operators. Likewise the current error reporting is not
precise to point out where in the expression String the problem is.
The implementation is using regular expressions, and that is one of
the key problems. I think we have grown to the limit how it is to
maintain.
So I have experimented this weekend to build a prototype based on the
principle of a recursive descent parser
http://en.wikipedia.org/wiki/Recursive_descent_parser
I at first looked into using a parser framework such as JavaCC and
ANTLR. The former would be able to parse the input, but building the
AST nodes would require to use its tree compiler, which was not maven
exposed. Likewise JavaCC is not really maintained anymore. People on
stackoverflow recommended ANTLR. It has more bells ans whistles, but
as far as I could see ANTLR requires JAR files in the runtime.
And frankly I just wanted a fairly simple code, that anybody, would be
able to look into and help with.
So I cracked up some prototype code based on the principle from that
wikipedia article above.
--
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com
--
Willem
----------------------------------
FuseSource
Web: http://www.fusesource.com
Blog: http://willemjiang.blogspot.com (English)
http://jnn.javaeye.com (Chinese)
Twitter: willemjiang
Weibo: willemjiang
