Interesting. That's not what I would have been expecting. May I inquire why this is done like this?
Once again, a solution chosen by the developer… I assume this is because the same XQJ base driver was used for a range of XQuery processors (eXist-db, Sedna, Marklogic).
Thus, my plug-in requires a common interface to the XQuery engines. XQJ seemed like the natural conterpart of javax.xml.transform used by the xml-maven-plugin, but I guess I really have to to write my own wrapper around Saxon's S9API and BaseX's API, if only because the XQJ integration seems to be among the least tested and most buggy parts of the XQuery engines I have tried so far.
I guess so. A clean abstraction for the Java and XQuery world often be helpful, but XQJ was discontinued at a rather early stage. One open issue from the very beginning was that it assumed the underlying processor to behave in certain ways, which did not reflect the reality of existing processors. And around 10 years ago, we were maintaining our own XQJ implementation, but it was too much effort to keep it alive (too few developers were using it).