Closed wyttenbach closed 3 months ago
wyttenbach
commented
3 months ago Okay I've since learned the 'unknown protocol' error is a red herring. For one thing this issue is sensitive to JDK version. Downgrading from JDK22 to JDK17 helped, but also I had an incorrect dependencyResource in the plugin configuration.
wyttenbach
commented
3 months ago Closing per previous comment
patrodyne
commented
3 months ago Dale, the HiSrc HigherJAXB v2.2.1 Maven plugin and its predecessors support "OASIS XML Catalog V1.0" as implemented by the plugin and by com.sun.org.apache.xml.internal:resolver:20050927:jar. The plugin implementation was developed by Alexey Valikov before 2010. The HigherJAXB plugin defines a custom URL protocol of the form, maven:group:artifact!/resource, where maven is the URL protocol (a.k.a. URI scheme) name. BTW, "Catalog V1.0" dates back to 2002 and is implemented by the jar referenced above. However, there is a newer "Catalog V1.1" which is implemented in the JVM XML Catalog since v9.
The XML Catalog specification defines how external references like XMLSchema can be replaced by local references; for example, replaced by a a copy of XMLSchema.xsd on your file system. The mapping is configured by either a catalog.xml file or by a deprecated catalog.cat format (TR9401). The catalog.xml file provides a variety of entries that are used to match external references in your xsd files, etc. The references are matched either by publicId or systemId. Those two terms originated in the DTD model but carry over to today's more modern XSD model. In today's model, the publicId refers to the XML namespace and the systemId refers to the local schema location (i.e. a local file name).
The ability to substitute local file schemas to resolve external network references improves your build process. Local files under source control are more stable and reliable than external references.
As stated, the HigherJAXB Maven plugin defines a custom URL protocol of the form, maven:group:artifact!/resource which is resolved using a custom class MavenCatalogResolver. The HigherJAXB Maven plugin provides a configurable parameter <catalogResolver>full-class-name</catalogResolver> to provide alternative resolvers; but, the MavenCatalogResolver is the current default. The XJC plugin which is invoked by the HigherJAXB Maven plugin provides an option to configure the resolver as an entityResolver. The term entity is used by the SAX/STAX parser libraries which do the actual XML parsing. In the JVM XML Catalog API, the CatalogResolver interfaces extends the EntityResolver interface.
Overall, there are three places where the XML Catalog API can be used to resolve external including custom schemes like maven: or classpath::
1) In the hisrc-higherjaxb-maven-plugin configuration in the POM.
2) In the catalog.xml (or in the deprecated TR9401 *.cat) file, as a systemId or uri target.
3) In your XML Schema (xsd) files by the actual XML parser.
The implementation of much of the above use cases in handled by this project's HigherJAXB Maven plugin. The first two use cases are processed by this project's plugin while the third use case is handled when the XJC plugin loads the model using the XML parser libraries.
When the XJC plugin is configured to use this project's MavenCatalogResolver it passes the reference to the XML parser library as an EntityResolver. The XML parser library invokes the EntityResolver which then calls back to this project's CatalogResolver implementation which uses "OASIS XML Catalog" API.
However, case #3 may also encounter the custom maven: scheme as a URL protocol, depending on context and the XML parser implementation. In release V2.2.1 and all of its predecessors (AFAIK), the maven: and classpath: methods are not implemented as a custom URL protocol; but only, as catalog/entity resolvers. The next release of this project's HigherJAXB Maven plugin will include an implementation of URLConnection for maven: and classpath: and for the first time using "OASIS XML Catalog V1.1" as provided by the JVM's built-in javax.xml.catalog API.
Note: The ability to extend the protocols that Java's URL class supports has been a feature for decades; however, the security constraints have grown. Relatedly, Maven itself has a tiered classpath model. The
URLandURLConnectionclasses provide three ways to add a custom protocol but only one way works with Maven's tiered classpath model. The next release of the HigherJAXB Maven plugin uses this one approach: URL.setURLStreamHandlerFactory(...).Warning: The URL.setURLStreamHandlerFactory(...) can be used by only one application per JVM instance. Because it is used in the next release, there may be conflicts with other APIs. So far my testing has work-arounds for the conflicts encountered.
It appears, that your build has encountered the URL protocol scenario under use case #3. I recommend you ruminate on the above explanation and perhaps you may see how to resolve your maven: reference using use cases #1 or #2. Caveat: Up to release V2.2.1, the Catalog API implementation has been carried along in the historic builds and may not have been thoroughly maintained.
Coincidentally, I am verifying the current build before committing the new implementation of "OASIS XML Catalog V1.1" as provided by the JVM's built-in javax.xml.catalog API. Note: The JVM's implementation does not
support the old TR9401 catalog.cat format; it supports the newer catalog.xml XML schema.
patrodyne
commented
3 months ago Also you should ensure when using catalogs, that you set <strict>false</strict> to reduce XJC and XML parser exceptions.
wyttenbach
commented
3 months ago Thank you so much!
I copied a working hisrc-higherjaxb30-maven-plugin/2.1.0 project and for some reason I am getting this 'unknown protocol' error in the new project. I've tried to compare the output of 'mvn -X' and I can't spot what is wrong. I did try upgrading to hisrc-higherjaxb30-maven-plugin/2.2.1 and mvn/3.9.8 but that didn't help.