The principle of not having *unnecessary* extra dependencies is good. However this looks to me more like reinventing the wheel. If we write all the code in Camel we won't have dependencies, but we get a bloated code base, hard to maintain and taking forever to test. Reusing code (and having dependencies) is a smarter path. I like the xtext idea and that can be externalized, as it was tried by Oisin, iiric, at camel-extra a while ago.
My $0.02, Hadrian On Aug 29, 2011, at 5:14 AM, Christian Schneider 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 > > > > 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 >
