gnodet commented on issue #13084: URL: https://github.com/apache/maven/issues/13084#issuecomment-5616994999
## Root cause found: commit `03c947d8` The culprit is [03c947d8 — "Restrict what a repository-resolved model contributes to the build"](https://github.com/apache/maven/commit/03c947d820889098701021d9a99b256358fde0cd), which landed on `maven-3.10.x`. ### What that commit does When a POM is built at `VALIDATION_LEVEL_MINIMAL` (i.e. any POM resolved from a remote repository during dependency collection — transitive deps, parents, imported BOMs), the commit suppresses profiles whose activation depends on a `<property>` or `<file>` condition. Only JDK, OS, and `activeByDefault` profiles survive. ### Why it breaks `resteasy-client:7.0.0.Final` The POM chain is: ``` resteasy-client:7.0.0.Final parent → resteasy-jaxrs-all:7.0.0.Final ``` `resteasy-jaxrs-all` has a profile `resteasy-default` with this activation: ```xml <activation> <property> <name>!resteasy.dependencies.eap</name> </property> </activation> ``` That profile is active by default (whenever `resteasy.dependencies.eap` is **not** set, which is the normal case). Its `<dependencyManagement>` contains the BOM import that supplies all the missing versions: ```xml <dependency> <groupId>org.jboss.resteasy</groupId> <artifactId>resteasy-dependencies</artifactId> <version>${project.version}</version> <type>pom</type> <scope>import</scope> </dependency> ``` With **Maven 3.9.x**: profile `resteasy-default` activates → BOM import applied → all 9 dep versions resolved ✅ With **Maven 3.10.x** (after `03c947d8`): `resteasy-jaxrs-all` is built at `VALIDATION_LEVEL_MINIMAL` → property-activated profiles are suppressed → `resteasy-default` is NOT activated → BOM import never added → 9 deps have no version → `ModelBuildingException` ❌ ### Confirmation This is **not** a Resolver regression. The `maven-3.10.x` branch uses the released Resolver 2.0.22, and nothing changed there that would affect BOM resolution in this way. The `03c947d8` commit is the only change on this branch that touches profile activation for externally-resolved models. ### Fix direction The `!property` negation pattern is effectively an "active unless explicitly disabled" idiom — it's semantically equivalent to `activeByDefault` from the author's intent. The current restriction is too broad: it silently drops profile-managed dependency versions for any project that uses property guards on its BOM-supplying profile. Options: 1. Treat `!property` (negated property, absent name) activation the same as `activeByDefault` for external models — i.e. allow it through since it's environment-independent. 2. Widen the allowed activations to include all property activations that only check for property **absence** (value unset). 3. Limit the profile suppression to only `<repositories>` and `<pluginRepositories>` contributions (not to the activation decision itself), keeping the full set of active profiles but stripping only the repo additions. Option 3 seems least invasive and avoids the broader question of which activations are "safe". -- 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]
