DDLDatabase cannot load relative paths in Maven modules that do not contain wildcards

[lukaseder]

Just like when specifying the <target/> directory (#2887), when specifying external configuration files, the Maven plugin should make sure to load files from relative paths relative to the module, not to the parent pom for repeatable builds.

Example:

<execution>
	<id>generate-externalconfigurationfile</id>
	<phase>generate-sources</phase>
	<goals>
		<goal>generate</goal>
	</goals>
	<configuration>
		<configurationFile>src/main/resources/externalconfigurationfile/externalconfigurationfile.xml</configurationFile>
	</configuration>
</execution>

When this is run in a maven module, currently, the canonical path resolved from the above relative path depends on whether the run command is issued from the module directory, or from the parent pom directory. The path should always be relative to the module directory.

[lukaseder]

Hmm, the file is already loaded from the right location in the plugin:

    private void read(String file) {
        getLog().info("Reading external configuration: " + file);
        File f = new File(file);

        if (!f.isAbsolute())
            f = new File(project.getBasedir(), file);

        FileInputStream in = null;
        try {
            in = new FileInputStream(f);

[lukaseder]

This is probably the same problem as #8336. When loading an external configuration file with relative paths, the relative paths are resolved with respect to the working directory not the module directory.

[lukaseder]

The issue observed here is different from #8336 as the relative path does not contain any wildcards. In the absence of wildcards, we're currently assuming that the file must exist, and in case we're running the code generation from a parent module, it doesn't seem to exist:

                if (file.exists()) {
                    load(encoding, file, fileComparator, null, loader);
                    loaded = true;
                }
                else if (pattern.contains("*") || pattern.contains("?")) {
                    file = new File(pattern.replaceAll("[*?].*", "")).getCanonicalFile();

                    Pattern regex = Pattern.compile("^.*?"
                       + pattern
                        .replace("\\", "/")
                        ...

The workaround for now is to scan the subdirectories of the working directory just like when there are wildcards.

A more thorough solution will be implemented through #8337

[lukaseder]

This current fix will introduce even more cases where too many files are loaded by a relative path configuration (see #8335), which may lead to regressions where accidental schema files from a different modules are matched and code is generated for that schema as well, or there are conflicting object names.

This is why this fix will not be backported to 3.11