[MNG-8694] Version not augmentable during runtime in Maven 4 as it was in Maven 3 #10394
Description
Nico Jahn opened MNG-8694 and commented
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.
Maven 4 breaks a working and simple pattern from Maven 3, without providing a proper replacement.
Without knowing if it is (and hoping it's not) actually an intended behavior, maybe a solution is already available. The error (see attached log) is during parsing by a regex. At exactly this place a comment to use an interpolation service instead was created and one day later it was added.
2024-10-02 f6417e4944
[MNG-8281] Interpolator service
MNG-8281 is Task according MNG-8262
2024-10-01 885a4b3a26
[MNG-8230] Rewrite CI friendly versions (#1710)
maven-model-builder/src/main/java/org/apache/maven/model/building/DefaultModelBuilder.java
location in current commit on master: /impl/maven-impl/src/main/java/org/apache/maven/impl/model/DefaultModelBuilder.java
603 String replaceCiFriendlyVersion(Map<String, String> properties, String version) {
604 // TODO: we're using a simple regex here, but we should probably use
605 // a proper interpolation service to do the replacements
606 // once one is available in maven-api-impl
607 // https://issues.apache.org/jira/browse/MNG-8262
Affects: 4.0.0-rc-3
Attachments:
- MNG-6894-log.txt (6.25 kB)
- revision-demo.zip (21.66 kB)
Remote Links: