[
https://issues.apache.org/jira/browse/MNG-7867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-7867:
--------------------------------
Summary: [REGRESSION]
'profiles.profile[ossrh].repositories.repository.[ossrh].url' contains an
expression but should be a constant (was: Maven 4 regression:
'profiles.profile[ossrh].repositories.repository.[ossrh].url' contains an
expression but should be a constant.)
> [REGRESSION] 'profiles.profile[ossrh].repositories.repository.[ossrh].url'
> contains an expression but should be a constant
> --------------------------------------------------------------------------------------------------------------------------
>
> Key: MNG-7867
> URL: https://issues.apache.org/jira/browse/MNG-7867
> Project: Maven
> Issue Type: Bug
> Reporter: Jörg Hohwiller
> Assignee: Guillaume Nodet
> Priority: Major
>
> 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.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
