Maven 4 rejects POM when xmlns:xsi uses HTTPS

[hazendaz]

Affected version

4.0.0-rc-5

Bug description

In Maven 3, I can change the xmlns:xsi namespace to use HTTPS instead of HTTP. I do this deliberately so automated scans can detect potential HTTP usage without triggering false positives for the canonical Maven POM namespace. The release plugin in Maven 3 provides a flag <addSchema>false</addSchema> to ignore this change, which has worked reliably for years.

In Maven 4, however, the same POM fails with:

org.apache.maven.api.services.xml.XmlReaderException: Unable to read model: Unknown attribute 'schemaLocation' for tag 'project'

Example POM snippet that is valid in Maven 3:

<project xmlns="https://maven.apache.org/POM/4.0.0"
         xmlns:xsi="https://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="https://maven.apache.org/POM/4.0.0
                             https://maven.apache.org/xsd/maven-4.0.0.xsd">

Problem:
Maven 4 is stricter in validating the xsi:schemaLocation attribute and does not allow the xmlns:xsi to use HTTPS. This breaks valid XML and creates unnecessary friction for teams trying to avoid HTTP usage in code audits. There is no flag or property in maven.config to bypass this validation, unlike Maven 3’s workaround with the release plugin.

Proposed improvement:
Maven should allow xmlns:xsi to use either http or https while still validating the POM, or provide a global flag in maven.config that disables strict schema validation for the POM entirely. This would:

1. Reduce false positives when scanning for HTTP URLs.
2. Maintain backward compatibility for teams using HTTPS namespaces.
3. Avoid requiring widespread removal or modification of xsi:schemaLocation in hundreds of POMs.

note: the namespace is still allowed to be https with maven 4. Only xmlns:xsi="https://www.w3.org/2001/XMLSchema-instance" is a problem.

[kwin]

The only valid namespace for XML Schema Instance is starting with "http:". Note that this is never used as URL for any request. I think there is a mixup between namespace and schemaLocation.

[hazendaz]

@kwin You are absolutely correct that the XML Schema Instance namespace is defined as
http://www.w3.org/2001/XMLSchema-instance and that it is an identifier, not a URL, and is never dereferenced by Maven itself.

I’m not disputing the correctness of that interpretation.

The issue I’m trying to highlight is a behavioral change between Maven 3 and Maven 4. Maven 3 tolerated this deviation and provided mechanisms (e.g. <addSchema>false</addSchema> in the release plugin) that allowed teams to intentionally suppress or work around schema-related validation without negative fallout. Many teams have relied on that leniency for years.

Maven 4 now enforces strict namespace validation with no equivalent opt-out. This turns what was previously a tolerated, low-risk customization into a hard failure and forces widespread changes across existing POMs with no functional benefit to the build itself.

While the namespace is formally “just an identifier”, in practice:

Humans read these files

IDEs auto-link the value and allow opening it

Simple static scans flag http: strings regardless of semantic intent

This creates significant noise during audits and reviews, which is why some teams intentionally altered the namespace value under Maven 3. The fact that this caused no practical issues for years is what makes the regression surprising.

To be clear, I am not asking Maven to redefine XML namespace semantics.
What I am asking for is one of the following:

• A global flag (e.g. in maven.config) to relax or disable strict schema validation for the POM, restoring Maven 3 behavior for teams that explicitly opt in.

• Or a documented, supported way to ignore or suppress this specific validation error.

This would preserve strict correctness by default while avoiding forced churn in large existing codebases that previously built cleanly under Maven 3.

If strict validation is the intended long-term direction, having an explicit compatibility or suppression mechanism would make the transition significantly less disruptive.

If neither of those is acceptable, then I think this change should at least be explicitly called out in the Maven 4 release notes or migration guide as a breaking change. Without that, teams upgrading from Maven 3 are likely to encounter failures that are difficult to diagnose, especially since the same POMs worked reliably for years and still appear valid in IDEs.

Even a short note in the “Incompatible / Breaking Changes” section would significantly reduce upgrade friction.

Speaking personally, this took some time to track down, as the switch to https was made long ago and the failure mode in Maven 4 is not immediately obvious. In fact, I entirely overlooked the error and assumed maven was no longer allowing its own namespace override to https.

[hazendaz]

Once reviewed, please feel free to close this issue. Thank you.

[elharo]

This is incorrect. That's not how namespaces work. It should fail when you do that. Don't do that.

And if Maven 3 isn't failing when you do that, there might be a bug in Maven 3. Or it might be that your Maven 3 toolchain is not using schema validation so it doesn't notice the error, and your Maven 4 toolchain is.