[
https://issues.apache.org/jira/browse/MNG-8694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nico Jahn updated MNG-8694:
---------------------------
Attachment: revision-demo.zip
> Version not augmentable during runtime in Maven 4 as it was in Maven 3
> -----------------------------------------------------------------------
>
> Key: MNG-8694
> URL: https://issues.apache.org/jira/browse/MNG-8694
> Project: Maven
> Issue Type: Wish
> Components: Reactor and Workspace
> Affects Versions: 4.0.0-rc-3
> Environment: MacOS Silicon
> Zulu Java 21
> Reporter: Nico Jahn
> Priority: Major
> Attachments: revision-demo.zip
>
>
> In Maven 3.x the revision property could be used to
> - dynamically define the final version of a project
> - while defining the version core (SemVer) hardcoded in the project setup.
> This is useful when defining special versions based on profiles.
> In our special case we do not inject version info from outside, but keep the
> version hardcoded and used profiles to augment the version during a build on
> a developer's computer by "-DEVELOPER" while enabling a build server to
> create a final release.
> Here a working example in Maven 3.x
> {{ <groupId>de.g667.m4-demo</groupId>}}
> {{ <artifactId>m4-demo-revision</artifactId>}}
> {{ <version>${revision}</version>}}
> {{ <packaging>pom</packaging>}}
> {{ <properties>}}
> {{ <versionCore>0.1.0</versionCore>}}
> {{ <revision>${versionCore}</revision>}}
> {{ </properties>}}
> {{ <profiles>}}
> {{ <profile>}}
> {{ <id>development</id>}}
> {{ <activation>}}
> {{ <property>}}
> {{ <name>!release</name>}}
> {{ </property>}}
> {{ </activation>}}
> {{ <properties>}}
> {{ <revision>${versionCore}-DEVELOPER</revision>}}
> {{ </properties>}}
> {{ </profile>}}
> {{ </profiles>}}
> Developer calls {{mvn clean install}}
> and produces Building {{m4-demo-revision 0.1.0-DEVELOPER}}
> Build server calls {{mvn clean install -Drelease}}
> and produces Building {{m4-demo-revision 0.1.0}}
> There are also more complex scenarios where other profiles are used to
> augment the version by additional data like a build number etc.
> With Maven 4 this does not work anymore. As far as I understand it is because
> Maven now resolves {{<version>}} before it evaluates {{<properties>}} and
> therefore returns
> {{[ERROR] Internal error: java.lang.IllegalArgumentException: No group with
> name \{versionCore} -> [Help 1]}}
> {{org.apache.maven.InternalErrorException: Internal error:
> java.lang.IllegalArgumentException: No group with name \{versionCore}}}
> After some investigation is seems there is no other way to reach our goal,
> without writing the version core at least twice in the pom files, which is
> error-prone.
> Especially since Maven gets "Full support of CI-friendly variables" and
> therefore the revision property can be used easier as before, it would also
> be nice to have the possiblity to enable version management like shown in the
> example. In some scenarios it is not feasible to inject versions externally,
> but ensure correct version management within the project setup directly.
> Handling version this way ensures version integrity accross multiple build
> systems during different development phases. Additionally when a whole
> software product line is maintained in multiple versions developers can
> simply switch between versions, build and reference their local build
> artifacts and dont have cross-effects on their machines.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
