[
https://issues.apache.org/jira/browse/MNG-8694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nico Jahn updated MNG-8694:
---------------------------
Description:
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.
was:
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.
> 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.
> Maven 4 breaks a working and simple pattern from Maven 3, without providing a
> proper replacement.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
