gnodet opened a new issue, #12435:
URL: https://github.com/apache/maven/issues/12435
## Summary
Maven 4 fails to build projects that use CI-friendly versions
(`${revision}`) when child modules have dependencies without explicit
`<version>` elements that rely on `dependencyManagement` inherited from the
parent. Maven 4 raises errors like `'dependencies.dependency.version' is
missing` during POM validation, before the dependency management inheritance
has been fully resolved.
## Affected projects (from Maven 4 compatibility testing)
### incubator-seata
Uses `${revision}` CI-friendly versioning. The `seata-all` module has ~20+
dependencies without explicit versions (spring-context, protostuff-core,
grpc-netty, postgresql, jackson-datatype-jsr310, kryo, junit-jupiter,
mockito-core, etc.) that are managed by the parent's `dependencyManagement`.
```
[ERROR] 'dependencies.dependency.version' for groupId='org.springframework',
artifactId='spring-context',
type='jar' is missing. @ org.apache.seata:seata-all:${revision},
.../project/all/pom.xml, line 359, column 9
[ERROR] 'dependencies.dependency.version' for groupId='io.protostuff',
artifactId='protostuff-core',
type='jar' is missing. @ org.apache.seata:seata-all:${revision},
.../project/all/pom.xml, line 563, column 9
```
(20+ similar errors for different dependencies)
Note: `mvnup apply` ran successfully on this project and modified many POMs,
but did not fix these missing version errors — it lacks a rule for this pattern.
## Analysis
The pattern is:
1. Parent POM defines `<version>${revision}</version>` and has comprehensive
`<dependencyManagement>`
2. Child modules declare `<dependency>` without `<version>`, relying on
inheritance from parent's `dependencyManagement`
3. Maven 3 resolved this correctly
4. Maven 4 validates dependency completeness before fully resolving the
`dependencyManagement` inheritance chain
This may be related to the `${revision}` CI-friendly version handling, where
the parent version contains an uninterpolated property — Maven 4 might fail to
load the parent's `dependencyManagement` when the parent's own version is
`${revision}`.
## Questions
- Is this a POM validation ordering issue (validation before
dependencyManagement inheritance)?
- Is this related to how `${revision}` affects parent POM resolution?
- Should `mvnup` add explicit versions to dependencies that rely on
inherited `dependencyManagement`?
--
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]
