[MNG-7867] [REGRESSION] 'profiles.profile[ossrh].repositories.repository.[ossrh].url' contains an expression but should be a constant

**[Jörg Hohwiller](https://issues.apache.org/jira/secure/ViewProfile.jspa?name=hohwille)** opened **[MNG-7867](https://issues.apache.org/jira/browse/MNG-7867?redirect=false)** and commented

With MNG-7047 new validation rules have been added to maven 4.
I always thought the maven devs finally started to understand that it is required to distinguish between the developer view on a POM and the consumer POM.
Your implementation in maven 4 validates the developer view on a POM and not the consumer POM.
I do have a generic parent POM that uses some variables as it is used by many child projects with their own repos like:
https://github.com/m-m-m/parent/blob/6e27d18337321c4f9d02e83c0b71313543555157/pom.xml#L378-L380
and
https://github.com/m-m-m/parent/blob/6e27d18337321c4f9d02e83c0b71313543555157/pom.xml#L360

This works fine in maven 3.x
My vision for Maven 4.x was that such variables would be replaced at build time and the POM that actually gets deployed for consumers could even be stripped from its parent hierarchy, etc.
Therefore my expectation is that in my pom.xml on the local disc such variable expressions are fully fine.
I am the original author of https://www.mojohaus.org/flatten-maven-plugin/ and my vision from the start was that this plugin should only be a temporary workaround and that maven could implement such features in much smarter way in its core so my plugin could then be thrown away.
Still in maven 4.x I am using the plugin and it will resolve these variables but the validation rules get into the way and break my build leading to a regession bug for something that works in maven 3.x.

Why can you implement to resolve the value of such expression if you want to have it static/fixed in the final POM?
Thanks for making maven and considering my thoughts.

---
No further details from [MNG-7867](https://issues.apache.org/jira/browse/MNG-7867?redirect=false)