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 > > -- Claus Ibsen ----------------- FuseSource Email: cib...@fusesource.com Web: http://fusesource.com Twitter: davsclaus, fusenews Blog: http://davsclaus.blogspot.com/ Author of Camel in Action: http://www.manning.com/ibsen/
