Emmanuel: I couldn't speak to the original intent, of course. I would support anything that would make JXPath less brittle--it's just been that given the existence of XPath 2, it's been somewhat an expectation that any substantial rewrite of JXPath would also incorporate support for the later spec, which has been touted as being a tall order (I really haven't researched it in any depth). Personally I have no experience with JavaCC, preferring ANTLR. JavaCC does yield no runtime dependencies, but we _could_ inline ANTLR dependencies were we to rewrite the parser...
-Matt --- On Fri, 5/29/09, Emmanuel Bourg <[email protected]> wrote: > From: Emmanuel Bourg <[email protected]> > Subject: [jxpath] Adding functions > To: "Commons Developers List" <[email protected]> > Date: Friday, May 29, 2009, 6:30 AM > I played a bit with JXPath today to > implement the ends-with() function. I thought it would be a > quick copy&paste of the starts-with() function, but that > was a little more tricky. The function is referenced in > several places, and I had to regenerate the parser with > JavaCC. > > I wonder if it would be possible to have a more modular > design for the core functions. Since there is already a > Function interface, the core functions could be implemented > as individual classes implementing this interface. But maybe > there was a reason for handling the core functions > differently from the user defined functions? > > Also worth noting, I tried to generate the parser with > JavaCC 4.1 through the Maven2 plugin but it failed. > StressTest displayed a huge call trace on the console and > died with an OutOfMemoryError, even with 1GB of RAM > allocated to Maven. > > Emmanuel Bourg > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
