Allow rewriting system ids for local files

[highsource]

No description provided.

[JulienCharon]

I have following situation: b/b.xsd imports a/a.xsd using relative paths, i.e. something like schemaLocation="../a/a.xsd".
I generate classes for a.xsd, and package them together with a.xsdto a jar.
Then, I try to generate classes for b.xsd using the jar as dependency and a catalog file rewriting the system id to maven:com.myproject:A:jar::!/schemas/a/a.xsd which results in a FileNotFoundException.
Is this meant by this issue?

[highsource]

Hi Julien,

I think I've created an issue because of your (or someone else's) question
on SO.
But I am not sure if this was exactly this one. I'll check in the evening.

Best wishes,
/Alexey

On Thu, Nov 27, 2014 at 9:38 AM, JulienCharon notifications@github.com
wrote:

I have following situation: b/b.xsd imports a/a.xsd using relative paths,
i.e. something like schemaLocation="../a/a.xsd".
I generate classes for a.xsd, and package them together with a.xsdto a
jar.
Then, I try to generate classes for b.xsd using the jar as dependency and
a catalog file rewriting the system id to
maven:com.myproject:A:jar::!/schemas/a/a.xsd which results in a
FileNotFoundException.
Is this meant by this issue?

—
Reply to this email directly or view it on GitHub
#19 (comment)
.

[highsource]

@JulienCharon Could you please provide a test case (sample project)?

[highsource]

@JulienCharon FYI thank you for the test case. Reproduced and working on it.

[highsource]

Ok, this is indeed an issue. The problem is that relative URIs like ../a/a.xsd first get resolved absolutely and then passed to the resolver. This is why this does not work:

REWRITE_SYSTEM "../a" "maven:org.jvnet.jaxb2.maven2:maven-jaxb2-plugin-tests-gh-issue-19-a:jar::!/a"

But this does:

REWRITE_SYSTEM "file:/C:/.../src/main/resources/a" "maven:org.jvnet.jaxb2.maven2:maven-jaxb2-plugin-tests-gh-issue-19-a:jar::!/a"

Since entity resolver does not get the base URI, "relativize" the absolute URI back, so it actually can't guess that ../a is actually that long absolute path. Blindly assuming local URIs for all relative URIs is also not good.

I think the solution should be some kind of expression like ${catalog.uri} or similar so that one could write

REWRITE_SYSTEM "${catalog.uri}/../a" "maven:org.jvnet.jaxb2.maven2:maven-jaxb2-plugin-tests-gh-issue-19-a:jar::!/a"

When the catalog is parsed, ${catalog.uri}/../a should first be resolved into the absolute URI like "file:/C:/.../src/main/resources/a". This would, however require to hack the catalog parsing.

[Milbor-zz]

Hi,
any updates on this issue? Is fix planned?
Thank you

[highsource]

This should be fixed in XJC.

The workaround for the maven-jaxb2-plugin is to use absolute URIs, even if you compile local files. Just invent some absolute URI and rewrite it via catalog.

[Milbor-zz]

Unfortunatelly we can not use proposed workaround for plugin as XSDs are provided by 3rd party with schemaLocation given as relative local file URI. Changing schemaLocation to arbitrary absolute URI every time we receive XSD update is not desirable.

Is this plugin issue planned to be fixed in the future?
Because of this we are not using catalogs and reverted to old way of unpacking dependencies during compilation.

[highsource]

You can still use this workaround. You just have to compile an URI instead of files.
Here's an example. This project compiles an URI http://schemas.opengis.net/wms/1.3.0/capabilities_1_3_0.xsd instead of local files. The catalog rewrites all the absolute URIs into artefact URIs which are processed locally from JAR files. The mentioned project compiles a lot of schemas, many of them have relative URLs and it works.

This is not a bug in the plugin, this is a problem in XJC. This XJC problem can be compensated for in the plugin, but since there's a workaround, this is not a high priority. We'd accept a Pull Request though.

[heatzync]

I have a different workaround that combines the build-helper-maven-plugin with the filter capabilities of the maven-resources-plugin. In the src/main/resources/catalog.cat file I have:

REWRITE_SYSTEM "file:${project.basedir}/src/main/resources/schemas/SomeSchema.xsd" "maven:za.co.group:ArtifactName:jar::!/xsd/SomeSchema.xsd"

and in the pom.xml I have the following:

  <build>
    <resources>
      <!--
      Copy and filter the catalog.cat file to ${project.build.directory}/classes before generating sources
      This is a very important step to get schemas imported using schemaLocations. For example, a schema that is imported with:
      <import schemaLocation="SomeFileInSameDirectory.xsd"/> then XJC translates the file path into an absolute path. This can be different on each
      computer. The catalog.cat file is used to rewrite this absolute path to another path where XJC will find the schema, but the absolute path
      needs to be taken into account.
      -->
      <resource>
        <directory>src/main/resources</directory>
        <filtering>true</filtering>
        <includes>
          <include>catalog.cat</include>
        </includes>
      </resource>
    </resources>

    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-resources-plugin</artifactId>
        <executions>
          <execution>
            <!-- This execution ensures the catalog.cat file is copied and filtered before the maven-jaxb2-plugin is executed -->
            <id>Filter catalog.cat</id>
            <phase>generate-sources</phase>
            <goals>
              <goal>resources</goal>
            </goals>
          </execution>
        </executions>
      </plugin>

      <plugin>
        <groupId>org.jvnet.jaxb2.maven2</groupId>
        <artifactId>maven-jaxb2-plugin</artifactId>
        <configuration>
          <strict>false</strict>
          <catalog>target/classes/catalog.cat</catalog>
          <bindings>
            <binding>
              <dependencyResource>
                <!-- reference to a binding file -->
              </dependencyResource>
            </binding>
          </bindings>
          <episodes>
            <episode>
              <!-- reference to an episode (JAR) -->
            </episode>
          </episodes>
        </configuration>
      </plugin>

      <plugin>
        <groupId>org.codehaus.mojo</groupId>
        <artifactId>build-helper-maven-plugin</artifactId>
      </plugin>
    </plugins>
  </build>

Note how the maven-jaxb2-plugin is configured to use the catalog.cat file that was output/filtered to target/classes/catalog.cat as opposed to the usual src/main/resources/catalog.cat

The content of target/classes/catalog.cat is output as:

REWRITE_SYSTEM "file:/absolute/path/to/project/src/main/resources/schemas/SomeSchema.xsd" "maven:za.co.group:ArtifactName:jar::!/xsd/SomeSchema.xsd"

[ScrambledRK]

In case someone stumbles over the same problem (resolving local xsd files to xsds provided in jars)
...

The above solution from @heatzync , as nice as it is, did not work for me. The internaly used MavenCatalogResolver was unable to resolve the given file path, no matter what I tried.

My workaround was to write a custom com.sun.tools.xjc.Plugin and set a custom EntityResolver replacing local file based URIs to http://something and setup the catalog.cat to resolve http://something URIs.

The plugin with custom resolver:

package;

import java.io.IOException;

import org.xml.sax.EntityResolver;
import org.xml.sax.InputSource;
import org.xml.sax.SAXException;

import com.sun.tools.xjc.BadCommandLineException;
import com.sun.tools.xjc.Options;

public class CustomResolverPlugin extends com.sun.tools.xjc.Plugin {

  //
  public String getOptionName() {
    return "Xcustom-resolver-plugin";
  }

  public String getUsage() {
    return "-Xcustom-resolver-plugin";
  }

  // --------------------------------------------------------------------------------------- //
  // --------------------------------------------------------------------------------------- //

  /**
   * Notifies a plugin that it's activated.
   */
  @Override public void onActivated( Options opts ) throws BadCommandLineException {
    opts.entityResolver = new CustomResolver( opts.entityResolver );
    super.onActivated( opts );
  }

  //
  static class CustomResolver implements EntityResolver {

    private final EntityResolver resolver;

    public CustomResolver( EntityResolver resolver ) {
      this.resolver = resolver;
    }

    //
    @Override public InputSource resolveEntity( String publicId, String systemId ) throws SAXException, IOException {

      if( systemId != null && systemId.endsWith( "the-local-schema-file.xsd" ) ) {
        systemId = "http://some-url/the-local-schema-file.xsd";
      }

      return resolver.resolveEntity( publicId, systemId );
    }
  }
}

The catalog.cat resolving fake http:// uris:

REWRITE_SYSTEM "http://some-url/the-local-schema-file.xsd" "maven:you-group:your-artifact:jar::!/path/to/the-local-schema-file.xsd"

[rudolfa]

I tried the above solution from @heatzync. First with no success. After some debugging I recognize, that ${project.basedir} used in catalog.cat expands on windows with file.separator="\".
So you receive something like below in your target/classes/catalog.cat:

REWRITE_SYSTEM "file:\\c:\\dev\\projectbasedir/src/main/resources/schemas/SomeSchema.xsd" "maven:za.co.group:ArtifactName:jar::!/xsd/SomeSchema.xsd"

To fix this I convert the variable content with help from build-helper-maven-plugin and regular expression.

<plugin>
        <groupId>org.codehaus.mojo</groupId>
        <artifactId>build-helper-maven-plugin</artifactId>
        <executions>
          <execution>
            <id>enforce-unix-fileseparator</id>
            <phase>validate</phase>
            <goals>
              <goal>regex-property</goal>
            </goals>
            <configuration>
              <value>${project.basedir}</value>
              <regex>\\</regex>
              <replacement>/</replacement>
              <name>project.basedir.unixfmt</name>
              <failIfNoMatch>false</failIfNoMatch>
            </configuration>
          </execution>
        </executions>
      </plugin>

and changed entries in catalog.cat to use the new variable:
REWRITE_SYSTEM "file:${project.basedir.unixfmt}/src/main/resources/schemas/SomeSchema.xsd" "maven:za.co.group:ArtifactName:jar::!/xsd/SomeSchema.xsd"

Now @heatzync's solution works without problems even under Windows

[laurentschoelens]

@ScrambledRK / @rudolfa
Could you please share a sample project that illustrate the above issue
It'd be nice to find a workaround in this plugin directly.
Thanks

[laurentschoelens]

@ScrambledRK / @rudolfa / @JulienCharon / @Milbor-zz / @heatzync : provided a PR that fixes this with a simple new parameter relativeCatalogResolution in plugin configuration.
Should be available in next release

[laurentschoelens]

Partial fix in 2.0.8 release for JDK11 / JDK17, but failed fix for JDK8 due to CatalogManager class collision between dependency and rt.jar