The idiomatic Maven solution for these parser-generator tools is to
invoke them from Maven plugins, rather than carrying snapshots of their
binaries in Xalan's /tools directory.
I did find a plugin for a newer version of java_cup, which might be
compatible; generated output code is not identical but is similar.
But... I haven't yet found a plugin for JLex.
I *did* find a Maven plugin for JFlex, which claims to have a "strict
JLex compatibility" mode.
Unfortunately, JFlex uses different data structures so our hand-coded
lookahead in the xpath.lex disambiguateAxisOrFunction() routine doesn't
work with jflex; we don't have direct access to yy_buffer,
yy_buffer_index, or yy_buffer_read. As a result, the expanded
XPathLexer.java code doesn't compile.
I can do another pass looking for a JLex plugin. If you happen to know
of one, a pointer would be welcome.
If that fails... JFlex does claim to support lookahead in its regex
implementations, so it should be possible to do the disambiguate at that
level and avoid having to code the lookahead ourselves. That's even a
better solution, stylistically. But I would have preferred to not
complicate the build porting process with actual code changes, so folks
could more easily compare the two and sanity-check me.
Quoting Steve Boies: "Make it work, make it good, make it great."
(Implied: In that order.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org
