[ 
https://issues.apache.org/jira/browse/MNG-8694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Guillaume Nodet updated MNG-8694:
---------------------------------
    Fix Version/s: 4.0.0-rc-4

> 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
>             Fix For: 4.0.0-rc-4
>
>         Attachments: MNG-6894-log.txt, 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.
> 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}}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to