hazendaz commented on issue #11693: URL: https://github.com/apache/maven/issues/11693#issuecomment-3861109835
@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```. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
