gnodet commented on code in PR #13059:
URL: https://github.com/apache/maven/pull/13059#discussion_r3955003677


##########
impl/maven-cli/src/main/java/org/apache/maven/cling/invoker/mvnup/goals/PluginUpgradeStrategy.java:
##########
@@ -523,49 +526,81 @@ && isPropertyUsedByQuarkusBom(pomDocument, propertyName)) 
{
 
     /**
      * Upgrades a property value if it represents a plugin version below the 
minimum.
+     * First checks the current POM's properties, then searches other POMs in 
the project
+     * (e.g., parent POMs) if the property is not found locally.
      */
     private boolean upgradePropertyVersion(
             Document pomDocument,
+            Map<Path, Document> pomMap,
             String propertyName,
             PluginUpgradeInfo upgrade,
             String sectionName,
             UpgradeContext context) {
-        Editor editor = new Editor(pomDocument);
-        Element root = editor.root();
+        // First, try the current POM's properties
+        if (upgradePropertyInDocument(pomDocument, propertyName, upgrade, 
sectionName, context)) {
+            return true;
+        }
+
+        // Property not found or not upgradable in current POM — search other 
POMs in the project
+        for (Map.Entry<Path, Document> entry : pomMap.entrySet()) {
+            Document otherDoc = entry.getValue();
+            if (otherDoc == pomDocument) {
+                continue; // Skip the current POM, already checked
+            }
+            if (upgradePropertyInDocument(otherDoc, propertyName, upgrade, 
sectionName, context)) {
+                return true;
+            }
+        }
+
+        // Property not found anywhere in the project
+        context.warning("Property " + propertyName + " not found in any 
project POM properties");

Review Comment:
   ⚠️ **Spurious warning when property is already at target version.**
   
   `upgradePropertyInDocument()` returns `false` for two distinct cases:
   1. Property element not found → fall-through to search other POMs is correct
   2. Property found but already at/above minimum → fall-through is **wrong**
   
   In case 2, the loop finds nothing in sibling POMs (the property is in the 
current POM, not there), falls through to this line, and emits `"Property X not 
found in any project POM properties"` — which is factually wrong. The property 
**was** found; it just didn't need upgrading.
   
   **Concrete scenario:** Root POM has 
`<exec.maven.version>3.5.0</exec.maven.version>` (already at target). Assembly 
submodule uses `<version>${exec.maven.version}</version>`. User runs `mvnup`. 
`upgradePropertyInDocument` on the current POM returns `false` (already at 
min), the pomMap loop finds nothing, warning fires. User sees a confusing "not 
found" message for a property that is perfectly defined.
   
   Fix: track whether the property was *found* (regardless of upgrade outcome) 
to suppress the false warning. Add an existence check before the search loop:
   
   ```suggestion
           // First, try the current POM's properties
           if (upgradePropertyInDocument(pomDocument, propertyName, upgrade, 
sectionName, context)) {
               return true;
           }
   
           // Check if property exists in the current POM but is already 
at/above min (no upgrade needed).
           // In that case, skip the cross-POM search and the warning — the 
property IS defined.
           Element currentRoot = pomDocument.root();
           Element currentProps = 
currentRoot.childElement(PROPERTIES).orElse(null);
           if (currentProps != null && 
currentProps.childElement(propertyName).isPresent()) {
               return false; // Found in current POM, no upgrade needed
           }
   
           // Property not in current POM — search other POMs in the project 
(e.g., parent POM)
           for (Map.Entry<Path, Document> entry : pomMap.entrySet()) {
               Document otherDoc = entry.getValue();
               if (otherDoc == pomDocument) {
                   continue; // Skip the current POM, already checked
               }
               if (upgradePropertyInDocument(otherDoc, propertyName, upgrade, 
sectionName, context)) {
                   return true;
               }
           }
   
           // Property not found anywhere in the project
           context.warning("Property " + propertyName + " not found in any 
project POM properties");
           return false;
   ```
   
   Also needs a test: single POM with 
`<exec.maven.version>3.5.0</exec.maven.version>` + submodule using 
`${exec.maven.version}` → no warning emitted, no modification.



##########
impl/maven-cli/src/test/java/org/apache/maven/cling/invoker/mvnup/goals/PluginUpgradeStrategyTest.java:
##########
@@ -712,6 +712,106 @@ void shouldNotUpgradeWhenPropertyNotFound() throws 
Exception {
             assertTrue(result.success(), "Plugin upgrade should succeed");
             // Note: POM might still be modified due to plugin management 
additions
         }
+
+        @Test
+        @DisplayName("should upgrade plugin with property version defined in 
parent POM")
+        void shouldUpgradePluginWithPropertyVersionInParentPom() throws 
Exception {
+            // Simulates hbase pattern: root POM defines 
<exec.maven.version>3.1.0</exec.maven.version>
+            // and submodule uses <version>${exec.maven.version}</version>
+            String parentPomXml = """
+                    <?xml version="1.0" encoding="UTF-8"?>
+                    <project xmlns="http://maven.apache.org/POM/4.0.0";>
+                        <modelVersion>4.0.0</modelVersion>
+                        <groupId>org.example</groupId>
+                        <artifactId>parent</artifactId>
+                        <version>1.0.0</version>
+                        <packaging>pom</packaging>
+                        <properties>
+                            <exec.maven.version>3.1.0</exec.maven.version>
+                        </properties>
+                        <modules>
+                            <module>assembly</module>
+                        </modules>
+                    </project>
+                    """;
+
+            String submodulePomXml = """
+                    <?xml version="1.0" encoding="UTF-8"?>
+                    <project xmlns="http://maven.apache.org/POM/4.0.0";>
+                        <modelVersion>4.0.0</modelVersion>
+                        <parent>
+                            <groupId>org.example</groupId>
+                            <artifactId>parent</artifactId>
+                            <version>1.0.0</version>
+                        </parent>
+                        <artifactId>assembly</artifactId>
+                        <build>
+                            <plugins>
+                                <plugin>
+                                    <groupId>org.codehaus.mojo</groupId>
+                                    <artifactId>exec-maven-plugin</artifactId>
+                                    <version>${exec.maven.version}</version>
+                                </plugin>
+                            </plugins>
+                        </build>
+                    </project>
+                    """;
+
+            Path tempDir = Files.createTempDirectory("mvnup-test-");
+            try {
+                Files.createDirectories(tempDir.resolve(".mvn"));
+                Path parentPomPath = tempDir.resolve("pom.xml");
+                Files.writeString(parentPomPath, parentPomXml);
+                Path assemblyDir = tempDir.resolve("assembly");
+                Files.createDirectories(assemblyDir);
+                Path submodulePomPath = assemblyDir.resolve("pom.xml");
+                Files.writeString(submodulePomPath, submodulePomXml);

Review Comment:
   💡 **Nit: dead filesystem I/O in this test.** `doApply(context, pomMap)` 
reads `Document` objects from the `pomMap` values — it does not read files from 
disk by path. The `Files.createDirectories(tempDir.resolve(".mvn"))` and 
`Files.writeString(...)` calls are never consumed by the strategy in a 
property-lookup scenario like this one. (The pre-existing tests that use a 
remote parent `org.apache:apache:23` trigger effective-model resolution which 
does need the filesystem — different situation.)
   
   These calls are harmless but add confusion. The test could be simplified: 
just construct `Document.of(xml)` and pass the in-memory map with any `Path` 
key (e.g., `Paths.get("pom.xml")`), same as `jarPluginTargetShouldBe342()` does.



-- 
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]

Reply via email to