kec opened a new issue, #13761: URL: https://github.com/apache/maven/issues/13761
### Affected version 4.0.0-rc-7. The code is unchanged at the head of `maven-4.0.x` (f05cc835a0, 2026-10-30), so the 4.0.0 release will carry it. 4.0.0-rc-5 is not affected. ### Bug description Since rc-7 the consumer POM no longer carries the property values written in the source POM. Every property set by a profile that happens to be active on the machine that runs `deploy` is written over the main `<properties>` block and over the same key in every other profile, active or not. The `-build.pom` is correct; only the consumer POM is rewritten. This changes what consumers get from a published parent or BOM: - a key a consumer inherits from the main block now holds the producer's environment-specific value instead of the declared default; - an opt-in profile that exists to set the key the other way is rewritten to the same value, so the switch no longer does anything; - an OS-activated profile for another platform is rewritten with the producer's value, so a consumer on that platform resolves the wrong classifier. #### Reproducer `pom.xml`, with an empty `.mvn/` directory beside it: ```xml <project xmlns="http://maven.apache.org/POM/4.0.0";> <modelVersion>4.0.0</modelVersion> <groupId>repro</groupId><artifactId>consumer-pom-profile-props</artifactId><version>1</version> <packaging>pom</packaging> <properties><flag>false</flag><classifier>none</classifier></properties> <profiles> <profile><id>active-here</id> <activation><file><missing>no-such-dir</missing></file></activation> <properties><flag>true</flag><classifier>here</classifier></properties></profile> <profile><id>opt-in</id> <activation><property><name>want.flag.off</name></property></activation> <properties><flag>false</flag></properties></profile> <profile><id>elsewhere</id> <activation><os><family>no-such-os</family></os></activation> <properties><classifier>elsewhere</classifier></properties></profile> </profiles> </project> ``` ``` mvn -B deploy -Dmaven.install.skip=true -DaltDeploymentRepository=local::file:///tmp/repo ``` Then read `/tmp/repo/repro/consumer-pom-profile-props/1/consumer-pom-profile-props-1.pom`. Nothing is passed on the command line, so the only active profile is `active-here`, whose `<missing>` condition holds on every machine. | | main `flag` | main `classifier` | `opt-in` profile `flag` | `elsewhere` profile `classifier` | |---|---|---|---|---| | source POM | false | none | false | elsewhere | | consumer POM, 4.0.0-rc-5 | false | none | false | elsewhere | | consumer POM, 4.0.0-rc-7 | **true** | **here** | **true** | **here** | Reproduced on 2026-10-30 with both distributions on the same machine (macOS, JDK 27). #### Where it comes from Two steps, both on `maven-4.0.x` today. 1. `DefaultConsumerPomBuilder.buildModel` puts the properties of every profile in `project.getActiveProfiles()` into the **user properties** of the `BUILD_CONSUMER` request, then the session's user properties on top: https://github.com/apache/maven/blob/f05cc835a0/impl/maven-core/src/main/java/org/apache/maven/internal/transformation/impl/DefaultConsumerPomBuilder.java#L593-L602 This arrived with MNG-8709 (#12684, merged 2026-08-26, fixing #10379), so that a dependency version supplied by an active profile's property interpolates and validates in the consumer build, which does not re-activate file-, property- or condition-activated profiles (#13004). rc-5 passed only `session.getUserProperties()`. 2. `DefaultModelBuilder` then treats everything in the request's user properties as a command-line override and writes it into the model: `merge(model.getProperties(), userProps)` for the main block and `merge(model.getProfiles(), userProps)` for every profile: https://github.com/apache/maven/blob/f05cc835a0/impl/maven-impl/src/main/java/org/apache/maven/impl/model/DefaultModelBuilder.java#L2006-L2013 (helpers at L2116 and L2142). That override exists so that `-Drevision=1.2.3` is baked into the consumer POM. It cannot tell a `-D` flag from a profile property any more, because step 1 put them in the same map. So the properties that MNG-8709 needed only for interpolation and validation are persisted as if the user had typed them, including values that are a function of the producer's file system, OS and JDK. #### Expected The consumer POM carries the property values as declared, in the main block and in each profile, exactly as rc-5 did. Only explicit user properties, the `-D` flags and CI-friendly versions, override declared values. Active-profile properties may feed interpolation and validation of the consumer model without being written into it. #### Possible fix Keep the active-profile properties available to interpolation, but take the override map from what the user actually passed, `request.getSession().getUserProperties()`, rather than from `request.getUserProperties()`. Alternatively carry the profile properties in their own request field that interpolation reads and the override step does not. Either way a test that deploys the reproducer and compares the consumer POM's properties, main block and per profile, with the source would hold the line. #### Impact seen in practice Our organisation's parent POM, built on macOS with a file-activated profile that turns documentation renderers off during the parent's own build, was published with every renderer disabled for all consumers and with the macOS artifact classifier inside its Linux and Windows profiles. Seven releases were affected before the cause was traced to the rc-7 upgrade. Parents and BOMs are the artifacts consumers inherit properties from, so the damage lands on every downstream project. -- 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]
