[MNG-8537] Keep Maven Namespace the same by elharo · Pull Request #10952 · apache/maven

elharo · 2025-07-19T12:23:56Z

Namespaces and model versions are not the same thing and do not serve the same purpose.

This PR has two related effects:

The namespace for all pom.xml files is now http://maven.apache.org/POM/4.0.0
Namespaces are not used to infer model versions. That's the job of the modelVersion element

Fixing this opens up Maven to the large and valuable XML toolchain. It makes it much easier for developers to analyze, store, and manipulate pom.xml files from a variety of languages without depending on complex Maven APIs and tooling. It decouples the poms from the Java source code. It is no longer necessary to use Maven libraries to process poms.

On the Maven side, it removes a roadblock to using standard XML parsers like Xerces instead of maintaining a separate custom XML parser. The more we can fit into the standard toolchains, the easier development becomes.

fixes #10692

elharo · 2026-03-19T17:43:33Z

something in the maven-shade-plugin is tripping a place I've missed:

Error:  Failed to execute goal org.apache.maven.plugins:maven-shade-plugin:3.5.0:shade (default) on project test: Error creating shaded jar: 1 problem was 
Error:      - [FATAL] Non-parseable POM /Users/runner/work/maven/maven/its/core-it-suite/target/test-classes/mng-7228-leaky-model/target/dependency-reduced-pom.xml: Invalid namespace 'http://maven.apache.org/POM/4.1.0' for model version 4.1.0 for project  at /Users/runner/work/maven/maven/its/core-it-suite/target/test-classes/mng-7228-leaky-model/target/dependency-reduced-pom.xml
Error:  -> [Help 1]

elharo · 2026-03-20T18:54:05Z

working on the first four.

On #5 I see the point. It's not immediately obvious to me whether ns or namespace is the namespace of the element. Digging.

    private void checkNamespace(XMLStreamReader parser, boolean strict, String namespace) throws XMLStreamException {
        if (strict) {
            String ns = parser.getNamespaceURI();
            if (!Objects.equals(namespace, ns)) {
                throw new XMLStreamException(
                    String.format("Unexpected namespace for element '%s': found '%s' but expected '%s'",
                        parser.getLocalName(),
                        ns != null ? ns : "no namespace",
                        namespace),
                    parser.getLocation(),
                    null
                );
            }
        }
    }

elharo · 2026-03-20T18:55:18Z

I think ChatGPT 4.1 found the cause of the remaining test failure. It's in the maven-shade-plugin where PomWriter tries to construct a namespace rather than simply copying the namespace of the source document:

https://github.com/apache/maven-shade-plugin/blob/b1b39fda298ab71b7194f30de443bdc90852b60e/src/main/java/org/apache/maven/plugins/shade/pom/PomWriter.java

Bukama

Note: We decided to keep the namespace as it is (at least for 4.0 release)

https://lists.apache.org/thread/h6d7wgq54fr84rmd65bddnwhwnxc7g62

- Add "the" before "project descriptor" (elharo's feedback) - Fix double preposition: "to which...conforms to" → "which...conforms to" - Drop contested inference sentence (pending PR #10952 resolution) Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

gnodet

AI Code Review — PR #10952

Verdict: 💬 COMMENT

Well-motivated PR that fixes the XML namespace to http://maven.apache.org/POM/4.0.0 for all model versions, decoupling namespace from modelVersion. The implementation is thorough — CI passes, and all areas flagged by gnodet's earlier review have been addressed (TransformerSupport, DefaultModelBuilder, maven.mdo, DefaultModelXmlFactory, and upgrade tooling).

However, the community has already decided via the mailing list to keep the namespace as-is for the 4.0 release (noted by Bukama, May 2026). The findings below are code-level observations for consideration if the approach is revisited.

Findings

#	Severity	File	Details
1	🟡 Medium	`UpgradeConstants.java:199-202`	Misleading constant name — `MAVEN_4_1_0_NAMESPACE` is defined as `"http://maven.apache.org/POM/4.0.0"`, identical to `MAVEN_4_0_0_NAMESPACE`. Having a constant named `4_1_0` with a `4.0.0` value is confusing. Consider a single `MAVEN_POM_NAMESPACE` constant instead.
2	🟢 Low	`ModelVersionUtilsTest.java:384`	Duplicate parameterized test entry — The `@ValueSource` now has `"http://maven.apache.org/POM/4.0.0"` twice (since the old 4.1.0 value was changed to 4.0.0). The test runs the same input redundantly. Additionally, `"https://maven.apache.org/POM/4.1.0"` still uses 4.1.0 with `https`, which seems inconsistent with the PR's goal.
3	🟡 Medium	`DefaultModelXmlFactory.java:66`	Backward compatibility concern — Namespace validation changed from `startsWith("http://maven.apache.org/POM/")` to strict `equals("http://maven.apache.org/POM/4.0.0")`. POMs deployed during Maven 4 pre-release with namespace `http://maven.apache.org/POM/4.1.0` would be rejected with a hard error. Consider accepting both during reading or documenting the migration path.

Context

Community decision: The mailing list thread (link) concluded to keep the namespace as-is for 4.0. This PR cannot merge without revisiting that decision.
External blocker: The maven-shade-plugin derives namespace URIs from model versions (acknowledged by the @Disabled test MavenITmng7228LeakyModelTest). A shade-plugin fix is needed for end-to-end correctness.
Comparison with #11185/#11186: This PR takes a fundamentally different and cleaner approach — removing version-varying namespaces entirely rather than restricting which are allowed. More principled from an XML standards perspective but also more disruptive.

This review was generated by an AI agent and may contain inaccuracies. Please verify all suggestions before applying.

Claude Code on behalf of Guillaume Nodet

Reviewed 3 PRs: apache#11146 (APPROVE), apache#10952 (COMMENT), apache#2106 (COMMENT). 24 total reviews posted. ~35 PRs remaining. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

gnodet

Code Review

All five findings independently confirmed. The PR decouples XML namespace from model version (fixing all namespaces to 4.0.0), but has several code quality issues:

Disabled integration test (MavenITmng7228LeakyModelTest.java:37): testLeakyModel is disabled with @Disabled due to maven-shade-plugin deriving namespace URIs from model versions. Disabling a pre-existing IT to work around an external plugin's broken behavior signals incomplete implementation.
Duplicate test parameter (ModelVersionUtilsTest.java:384): The @ValueSource contains a duplicate entry — both first and second strings are "http://maven.apache.org/POM/4.0.0". The fourth entry "https://maven.apache.org/POM/4.1.0" retains 4.1.0, inconsistent with the PR's namespace normalization goal.
Backward compatibility risk (DefaultModelXmlFactory.java:67): Namespace validation changed from startsWith("http://maven.apache.org/POM/") to strict equals("http://maven.apache.org/POM/4.0.0"). This could reject POMs deployed during the Maven 4 RC period with xmlns="http://maven.apache.org/POM/4.1.0".
Mismatched assertion message (UpgradeWorkflowIntegrationTest.java:91): Assertion message says "POM should be upgraded to 4.1.0 namespace" but the assertion checks for 4.0.0 — a copy-paste oversight.
Dead code constants (UpgradeConstants.java): New 234-line constants file partially duplicates domtrip's MavenPomElements class and is not imported or referenced by any other file in the diff or codebase. Additionally, Namespaces.MAVEN_4_1_0_NAMESPACE is defined as "http://maven.apache.org/POM/4.0.0" — a confusingly named constant whose value doesn't match its name.

Note: The Maven community has decided via mailing list to keep the namespace as-is for the 4.0 release, and the maintainer has formally requested changes deferring this to 5.0.

This review was generated by an AI agent and may contain inaccuracies. Please verify all suggestions before applying.

Claude Code on behalf of gnodet

gnodet

Code Review

The architectural motivation is sound — decoupling XML namespace from modelVersion addresses a real design concern. However, the community has already decided via the dev mailing list to keep the namespace as-is for the 4.0 release, and this PR has several code quality issues that would need to be addressed if revived for 5.0:

Issues Found

1. Integration test disabled rather than fixed (high)
MavenITmng7228LeakyModelTest.java — testLeakyModel is disabled with @Disabled to work around maven-shade-plugin incorrectly deriving namespace URIs from model versions. Disabling a pre-existing IT rather than fixing the root cause in the shade plugin signals an incomplete implementation.

2. Backward compatibility risk in namespace validation (high)
DefaultModelXmlFactory.java — Namespace validation changed from startsWith("http://maven.apache.org/POM/") to strict equals("http://maven.apache.org/POM/4.0.0"). POMs published during the Maven 4 RC period with xmlns="http://maven.apache.org/POM/4.1.0" would be rejected with a hard error. No migration path is provided.

3. Dead code: UpgradeConstants.java (medium)
New 234-line file UpgradeConstants.java is not imported by any other file in the diff. The files that use namespace constants import from eu.maveniverse.domtrip.maven.MavenPomElements instead.

4. Misleading duplicate constants (medium)
MAVEN_4_1_0_NAMESPACE is defined as "http://maven.apache.org/POM/4.0.0", identical to MAVEN_4_0_0_NAMESPACE. A single MAVEN_NAMESPACE constant would be clearer.

5. Assertion message mismatch (medium)
UpgradeWorkflowIntegrationTest.java line 91 — message says "4.1.0 namespace" but the assertion checks for the 4.0.0 value.

6. Loosened test assertion (low)
MavenStaxReaderTest.java — error message assertion changed from a specific namespace string to a less specific prefix match.

Notes

Of the 189 changed files, 174 are mechanical XML namespace replacements (safe). The risk is concentrated in ~6 Java files with behavioral changes.
The PR is currently in a CONFLICTING state with master (370+ days old, 50 commits). If revived for 5.0, the commit history should be squashed.

This review was generated by an AI agent and may contain inaccuracies. Please verify all suggestions before applying.

Claude Code on behalf of gnodet

gnodet

Review Summary

The architectural motivation is sound — decoupling namespace from modelVersion is good XML practice and would enable standard XML tooling for POM files. However, there are several code quality issues from the mechanical namespace replacement, plus a process concern noted below.

1. 🔴 Disabled integration test rather than fixed (high)

File: its/core-it-suite/src/test/java/org/apache/maven/it/MavenITmng7228LeakyModelTest.java

The pre-existing testLeakyModel IT is disabled with @Disabled("Disabled because the maven-shade-plugin incorrectly derives namespace URIs from model versions") rather than fixed. This signals an external dependency blocker — the maven-shade-plugin would need updating to handle the namespace change.

2. 🔴 Tightened namespace validation breaks RC-period POMs (high)

File: impl/maven-impl/src/main/java/org/apache/maven/impl/DefaultModelXmlFactory.java

Namespace validation changes from startsWith("http://maven.apache.org/POM/") to strict equals("http://maven.apache.org/POM/4.0.0"). Any POMs published during the Maven 4 RC period with xmlns="http://maven.apache.org/POM/4.1.0" would be rejected with a hard error. No migration path or deprecation period is provided.

3. 🟡 `UpgradeConstants.java` is dead code (medium)

File: impl/maven-cli/src/main/java/org/apache/maven/cling/invoker/mvnup/goals/UpgradeConstants.java

The new 234-line constants file is never imported or referenced by any other file in the diff or existing codebase. The code that previously used similar constants now imports from the external library eu.maveniverse.domtrip.maven.MavenPomElements.Namespaces.

4. 🟡 Misleading constant name (medium)

File: impl/maven-cli/src/main/java/org/apache/maven/cling/invoker/mvnup/goals/UpgradeConstants.java

MAVEN_4_1_0_NAMESPACE is defined as "http://maven.apache.org/POM/4.0.0", identical to MAVEN_4_0_0_NAMESPACE. While intentional for namespace unification, the constant name strongly implies a different URI. A single MAVEN_POM_NAMESPACE constant would be clearer.

5. 🟡 Assertion message mismatch (medium)

File: impl/maven-cli/src/test/java/org/apache/maven/cling/invoker/mvnup/goals/UpgradeWorkflowIntegrationTest.java

Assertion message says "POM should be upgraded to 4.1.0 namespace" but the assertion actually checks for the 4.0.0 value — a copy-paste oversight from the mechanical find-and-replace.

6. 🔵 Duplicate `@ValueSource` entry (low)

File: impl/maven-cli/src/test/java/org/apache/maven/cling/invoker/mvnup/goals/ModelVersionUtilsTest.java

The @ValueSource at line 384 contains "http://maven.apache.org/POM/4.0.0" twice (the 4.1.0 entry was mechanically replaced to 4.0.0, duplicating the existing entry). This runs the same test case twice and reduces coverage — the http 4.1.0 case is no longer tested.

📋 PR Metadata

Aspect	Current	Suggested
Milestone	(none)	`5.x`

Note: Per the dev mailing list discussion, the community decided to keep the current namespace scheme for 4.0 GA. This PR would be a candidate for the 5.x timeframe if revisited.

_{🤖 This review was generated by ForgeBot. Feedback? File an issue on the ForgeBot repo.}

gnodet

Several issues found in this PR:

Disabled integration test — MavenITmng7228LeakyModelTest is disabled with @Disabled citing maven-shade-plugin as the root cause, rather than fixing the underlying issue. The IT should remain enabled to detect future regressions.
Dead code — UpgradeConstants.java (234 lines) is never imported or referenced anywhere in this PR's diff. The constants it defines duplicate those already in MavenPomElements, which other files modified in this PR already import directly.
Removed test coverage for 4.1.0/4.2.0 namespaces — ModelVersionUtilsTest removes shouldDetectModelVersionFromNamespace (which tested version detection for 4.0.0, 4.1.0, 4.2.0) and shouldDetectVersionFromNamespaceWhenModelVersionMissing (which tested 4.1.0 namespace detection). Removing these tests reduces coverage precisely for the behavior this PR is changing.
Stale comment — A comment reading // Update namespace based on target model version remains after the code was changed to hardcode Namespaces.MAVEN_4_0_0_NAMESPACE regardless of the target model version.
Namespace validation regression — DefaultModelXmlFactory changes startsWith("http://maven.apache.org/POM/") to equals("http://maven.apache.org/POM/4.0.0"), which will cause POMs with 4.1.0 or 4.2.0 namespace URIs to throw an XmlReaderException that previously passed validation.

This review was generated by an AI agent, Hermès on behalf of @gnodet.

gnodet · 2026-10-11T06:13:21Z

        super();
    }

+    @Disabled("Disabled because the maven-shade-plugin incorrectly derives namespace URIs from model versions")


⚠️ Avoids root cause: This test is disabled with @Disabled citing maven-shade-plugin as the root cause, but the fix belongs either in Maven itself or in the shade plugin. Disabling the IT hides the regression. If this is a known external plugin issue, consider filing a bug upstream and tracking it with an issue reference rather than silently disabling the test.

gnodet · 2026-10-11T06:13:21Z

+ * Constants used throughout the Maven upgrade tools.
+ * Organized into logical groups for better maintainability.
+ */
+public final class UpgradeConstants {


⚠️ Dead code: This 234-line class is never imported or referenced by any other file in this PR. The constants it defines (ModelVersions, Namespaces, schema locations) duplicate those already available from MavenPomElements, which other files in this PR already import. Please remove this file and use the existing constants from MavenPomElements instead.

gnodet · 2026-10-11T06:13:21Z


        // Update namespace based on target model version
-        String targetNamespace = getNamespaceForModelVersion(targetModelVersion);
+        String targetNamespace = Namespaces.MAVEN_4_0_0_NAMESPACE;


📝 Stale comment: The comment on line 182 reads // Update namespace based on target model version, but the code now hardcodes Namespaces.MAVEN_4_0_0_NAMESPACE regardless of targetModelVersion. Update the comment to reflect the actual behavior (e.g. // Always upgrade to Maven 4.0.0 namespace).

gnodet · 2026-10-11T06:13:21Z

        Model model = doRead(request);
        if (isModelVersionGreaterThan400(model)
-                && !model.getNamespaceUri().startsWith("http://maven.apache.org/POM/")) {
+                && !model.getNamespaceUri().equals("http://maven.apache.org/POM/4.0.0")) {


⚠️ Compatibility regression: Changing from startsWith("http://maven.apache.org/POM/") to equals("http://maven.apache.org/POM/4.0.0") means any POM with a 4.1.0 or 4.2.0 namespace URI will now throw an XmlReaderException where it previously passed. If the intent is to restrict namespace handling to 4.0.0 POMs in this path, this needs to be documented, tested for the rejection behavior, and confirmed to not break existing 4.1.0 workloads.

gnodet-bot

Following up on the previous reviews — the new commits ("Remove NAMESPACE_PREFIX", "import", "reason") add further changes to the namespace decoupling logic, but all four issues flagged in the October 2026 review remain unaddressed. Two additional issues are identified in this version.

Status of October 2026 findings:

⚠️ Disabled integration test — still open
⚠️ Dead code (UpgradeConstants.java) — still open
⚠️ Duplicate @ValueSource entry — still open
⚠️ Stale comment in ModelUpgradeStrategy — still open

This review was generated by an AI agent, Hermès on behalf of @gnodet.

gnodet-bot · 2026-10-29T04:25:25Z

@@ -33,6 +34,7 @@ protected MavenITmng7228LeakyModelTest() {
        super();
    }



⚠️ Avoids root cause (still unaddressed): testLeakyModel is disabled citing maven-shade-plugin as the cause, but this test verifies that Maven itself does not produce a consumer POM with a namespace that breaks downstream tools. The shade plugin failure is a symptom — Maven's consumer POM writer is producing POMs with inconsistent namespaces. Disabling this IT hides a real Maven regression.

Options:

Fix the consumer POM writer to always emit the 4.0.0 namespace (the intent of this PR)

If the shade plugin genuinely can't handle the new namespace yet, track it as a known limitation with a link to the upstream bug and a TODO to re-enable when shade is fixed

Restructure the IT to avoid using shade plugin, exercising the namespace leakage through a different path

Leaving this disabled without a tracking issue or re-enable condition is not acceptable.

gnodet-bot · 2026-10-29T04:25:25Z

+ * Constants used throughout the Maven upgrade tools.
+ * Organized into logical groups for better maintainability.
+ */
+public final class UpgradeConstants {


⚠️ Dead code (still unaddressed): This 234-line class is not imported by any other file in this PR. ModelUpgradeStrategy was updated to import MavenPomElements.Namespaces directly (not UpgradeConstants.Namespaces). ModelVersionUtils inlines its schema location strings. All constants defined here (ModelVersions, XmlElements, Indentation, Plugins, Files, Namespaces, SchemaLocations, XmlAttributes) duplicate what's already in MavenPomElements or are unused.

Remove this file.

gnodet-bot · 2026-10-29T04:25:25Z

+        public static final String MAVEN_4_0_0_NAMESPACE = "http://maven.apache.org/POM/4.0.0";
+
+        /** Maven namespace URI */
+        public static final String MAVEN_4_1_0_NAMESPACE = "http://maven.apache.org/POM/4.0.0";


🔴 Wrong constant value (new issue): MAVEN_4_1_0_NAMESPACE is defined as "http://maven.apache.org/POM/4.0.0" — identical to MAVEN_4_0_0_NAMESPACE. The constant name says 4.1.0 but the value is 4.0.0. This is either a copy-paste error or an intentional conflation — either way, the constant name is actively misleading. Any code using MAVEN_4_1_0_NAMESPACE expecting a 4.1.0 URI would silently get the 4.0.0 URI instead.

This class should be removed (see the dead code finding above). If it's kept, correct the constant name or value.

gnodet-bot · 2026-10-29T04:25:25Z

        @ValueSource(
                strings = {
                    "http://maven.apache.org/POM/4.0.0",
-                    "http://maven.apache.org/POM/4.1.0",
+                    "http://maven.apache.org/POM/4.0.0",


⚠️ Duplicate test entry (still unaddressed): After replacing "http://maven.apache.org/POM/4.1.0" with "http://maven.apache.org/POM/4.0.0", the @ValueSource now has "http://maven.apache.org/POM/4.0.0" twice (lines 383 and 384). This removes the test coverage for 4.1.0 as a valid namespace, and runs the same 4.0.0 case twice — which provides no additional confidence.

Replace this duplicate with a test for the 4.1.0 namespace (which should now also validate to 4.0.0 under the new model, if that's the intent), or remove the duplicate entry.

gnodet-bot · 2026-10-29T04:25:25Z


        // Update namespace based on target model version
-        String targetNamespace = getNamespaceForModelVersion(targetModelVersion);
+        String targetNamespace = Namespaces.MAVEN_4_0_0_NAMESPACE;


📝 Stale comment (still unaddressed): The comment says // Update namespace based on target model version but the code directly below hardcodes Namespaces.MAVEN_4_0_0_NAMESPACE regardless of targetModelVersion. The comment is wrong.

gnodet-bot · 2026-10-29T04:25:26Z

        Model model = doRead(request);
        if (isModelVersionGreaterThan400(model)
-                && !model.getNamespaceUri().startsWith("http://maven.apache.org/POM/")) {
+                && !model.getNamespaceUri().equals("http://maven.apache.org/POM/4.0.0")) {


🔴 Compatibility regression: Changing startsWith("http://maven.apache.org/POM/") to equals("http://maven.apache.org/POM/4.0.0") means any POM with modelVersion > 4.0.0 that still uses a version-specific namespace (xmlns="http://maven.apache.org/POM/4.1.0") will now throw XmlReaderException: Invalid namespace '...'.

The test for this case (testValidNamespaceWithModelVersion410) was updated to use the 4.0.0 namespace in the test input itself — which means it no longer tests the real-world scenario of a 4.1.0 POM with its pre-existing namespace. Any user who has a POM with xmlns="http://maven.apache.org/POM/4.1.0" and builds against this Maven version will get a hard parse failure.

If the intent is that all POMs must migrate their namespace to 4.0.0 before this Maven version can read them, document this migration requirement explicitly in the error message. If the intent is forward-compatibility, use startsWith or accept any valid Maven namespace.

gnodet-bot · 2026-10-29T04:25:26Z

            String upgradedPom = Files.readString(pomFile);
            assertTrue(
-                    upgradedPom.contains("http://maven.apache.org/POM/4.1.0"),
+                    upgradedPom.contains("http://maven.apache.org/POM/4.0.0"),


📝 Stale assertion message (new issue): The assertion message still says "POM should be upgraded to 4.1.0 namespace" but the assertion now checks for contains("http://maven.apache.org/POM/4.0.0"). When this assertion fails, the message will mislead the developer.

elharo added 3 commits July 19, 2025 07:07

revert namespace

b7ea8a4

fix tests

0655cb7

tests

523d67c

elharo changed the title ~~Revert Namespace~~ [MNG-8537] Revert Namespace Jul 19, 2025

elharo added 15 commits July 19, 2025 10:34

fix ITs

eb98d63

fix IT

cf1c35d

fix IT

91995f0

fix IT

202ecd1

fix IT

f96feff

fix IT

e05e573

fix IT

4621bcd

fix IT

d935cb5

fix mng-6957

f13b879

fix IT

1f40af6

fix IT

2eef2bd

fix IT

13dd6f4

fix IT

c16d2b4

fix IT

66372a5

fix IT

e14cc45

elharo marked this pull request as ready for review July 20, 2025 10:58

elharo requested review from cstamas, gnodet, michael-o, rfscholte, slachiewicz and slawekjaranowski July 20, 2025 10:59

elharo added 2 commits July 20, 2025 07:07

Merge branch 'master' into namespace

5b74418

revert unrelated docs

356e21a

elharo changed the title ~~[MNG-8537] Revert Namespace~~ [MNG-8537] Keep Maven Namespace the same Jul 20, 2025

elharo requested a review from Bukama July 20, 2025 11:24

elharo added 11 commits March 19, 2026 07:13

superpoms

f29f4f7

fix

ec0a483

IT tests

acf07f6

More ITs

f3f1ea3

testFuture

2e7f3c2

one more

bad236e

inline unreliable constants

3737a8c

mng-7804-plugin-execution-order

3e88f1c

Missing modelVersion

d1443cf

4.2.0

4d7253e

4.2.0

dbff949

elharo added 3 commits March 19, 2026 13:45

Missing modelVersion

467eec2

mng-8750-new-scopes/validation-failure-test/pom.xml

8e5c758

Remove NAMESPACE_PREFIX

1a4261a

elharo added 2 commits March 20, 2026 15:17

import

561ce14

reason

bb6351a

Bukama reviewed May 28, 2026

View reviewed changes

gnodet added mvn4 enhancement New feature or request labels Jun 22, 2026

gnodet reviewed Jul 10, 2026

View reviewed changes

gnodet reviewed Jul 24, 2026

View reviewed changes

gnodet reviewed Aug 28, 2026

View reviewed changes

gnodet requested changes Oct 11, 2026

View reviewed changes

gnodet-bot suggested changes Oct 29, 2026

View reviewed changes

		@@ -33,6 +34,7 @@ protected MavenITmng7228LeakyModelTest() {
		super();
		}

Conversation

elharo commented Jul 19, 2025 • edited by hboutemy Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

elharo commented Mar 19, 2026

Uh oh!

elharo commented Mar 20, 2026

Uh oh!

elharo commented Mar 20, 2026

Uh oh!

Bukama left a comment

Choose a reason for hiding this comment

Uh oh!

gnodet left a comment

Choose a reason for hiding this comment

AI Code Review — PR #10952

Findings

Context

Uh oh!

gnodet left a comment

Choose a reason for hiding this comment

Code Review

Uh oh!

gnodet left a comment

Choose a reason for hiding this comment

Code Review

Issues Found

Notes

Uh oh!

gnodet left a comment

Choose a reason for hiding this comment

Review Summary

1. 🔴 Disabled integration test rather than fixed (high)

2. 🔴 Tightened namespace validation breaks RC-period POMs (high)

3. 🟡 UpgradeConstants.java is dead code (medium)

4. 🟡 Misleading constant name (medium)

5. 🟡 Assertion message mismatch (medium)

6. 🔵 Duplicate @ValueSource entry (low)

📋 PR Metadata

Uh oh!

gnodet left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

gnodet-bot left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

elharo commented Jul 19, 2025 •

edited by hboutemy

Loading

3. 🟡 `UpgradeConstants.java` is dead code (medium)

6. 🔵 Duplicate `@ValueSource` entry (low)