jkesselm commented on PR #2:
URL: https://github.com/apache/xalan-java/pull/2#issuecomment-1589896109
This seems to be mixing a number of issues -- the JLex question, the more
general question of where the dependency jarfiles should live and how they are
fetched, and running continuous integration. I'd be happier if we could divide
these and address them separately.
-----
XPathLexer appears to be generated from xpath.lex using JLex, according to
the build.xml file. See the property ${generated.xpathlexer" and its usage. So
we *DO* have checked-in source for that in the Xalan-Java project.
The problem is that we don't have either source, or a source, for JLex.
Last I checked, it wasn't clear who actually owns/maintains JLex. If anyone.
The proper solution would be to find a supported (or at least clearly
open-sourced) Java lex implementation compatible with any JLex quirks (and/or
to rework the input to work with the new lex) and swap it in. That's a somewhat
scary proposal, deserving its own work item.
Note that JLex and XPathLexer are part of the xsltc "compiled xslt
processor" code, originally contributed to Apache by Sun Microsystems. I did a
lot of the work to reconcile that code with Xalan and glue them together as a
single system... but I didn't go very deeply into it at the time, just enough
to sew the monster together. A significant portion of Sun's code was accepted
unexamined before I even started that process, which is how JLex got brought
in. Yes, these days Apache would insist on knowing the source of all the
pieces, but things were a bit looser then; as long as Sun took responsibility
for the code donation, we trusted that they had either written it themselves or
sourced it ethically.
Good luck finding someone at Sun who remembers where they got JLex from,
especially since they pretty much vanished from the Xalan project after the
integration.
I think we just have to accept this as grandfathered code until/unless
someone is willing to tackle either tracking it down (and dealing with any
changes since we got our copy that might affect our use of it) or replacing it.
Either way, I'd want to see that tested to death before committing to it.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org
