[
https://issues.apache.org/jira/browse/MNG-6608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16792724#comment-16792724
]
Markus Meisterernst commented on MNG-6608:
------------------------------------------
Hi,
since Maven 3.5 you can make use of built in Variables revision,sha1 and
changelist that are expected to be interpolated. This feature seems to be
usable in version 3.6 the first time:
https://maven.apache.org/docs/3.6.0/release-notes.html
So, [~chen.kline] you can make use of ${revision} and a respective revision
property to achieve what you want to.
see: https://maven.apache.org/maven-ci-friendly.html
YOU HAVE TO USE THE FOLLOWING PLUGIN TO MAKE IT WORK FOR THE CI BUILD AND
DEVELOPERS ALIKE:
{code:java}
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>flatten-maven-plugin</artifactId>
</plugin>{code}
Otherwise you are not able to build Sub-Modules on their own (without always
doing a full blown build from the top level - that's what Developers intend to
do to save build time). You get Errors if you build a Sub Module that has other
Project internal Dependencies (here lib-api) if you don't make use of the
flatten-maven-plugin:
{code:java}
lib-impl markus$ mvn clean install
[INFO] Scanning for projects...
[INFO]
[INFO] ------------------------< org.example:lib-impl >------------------------
[INFO] Building lib-impl 1.0-SNAPSHOT
[INFO] --------------------------------[ jar ]---------------------------------
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 0.276 s
[INFO] Finished at: 2019-03-14T14:34:19+01:00
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal on project lib-impl: Could not resolve
dependencies for project org.example:lib-impl:jar:1.0-SNAPSHOT: Failed to
collect dependencies at org.example:lib-api:jar:1.0-SNAPSHOT: Failed to read
artifact descriptor for org.example:lib-api:jar:1.0-SNAPSHOT: Failure to find
org.example:revision-test:pom:${revision} in
https://repo.maven.apache.org/maven2 was cached in the local repository,
resolution will not be reattempted until the update interval of central has
elapsed or updates are forced -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please
read the following articles:
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/DependencyResolutionException{code}
As you can see, it tries to resolve
{code:java}
dependencies at org.example:lib-api:jar:1.0-SNAPSHOT{code}
but look's up:
{code:java}
org.example:revision-test:pom:${revision}{code}
due to the fact, that the root pom in the local repository isn't flattened,
that means it hasn't its variables interpolated.
Find attached the Example Project I used for exploration of this new, however,
still (in my opinion somehow) "broken" feature.
[^revision-test.zip]
My personal belief is that *this whole versioning stuff is more complicated as
it should be due to the fact that information is replicated all over the
place*. This clearly violates the "single source of truth" paradigm.
>From my perspective it should be sufficient to have a single <version> defined
>in the reactor pom and that's it.
You should be able to reference to the parent pom by using the <parent>-section
then as such:
{code:java}
<parent>
<artifactId>revision-test</artifactId>
<groupId>org.example</groupId>
<relativePath>../pom.xml</relativePath>
</parent>{code}
This snippet has all the information it needs, to look up the parent POM by
following the relative path and so on up to the reactor pom, where it should be
able to find its version (being either a ${revision} or a fixed value set).
Unfortunately <version> in the <parent> section is mandatory (they would have
to change the XSD schema I guess), which really is a pity.
> Why can't project.version in pom.xml be set as a variable?
> ----------------------------------------------------------
>
> Key: MNG-6608
> URL: https://issues.apache.org/jira/browse/MNG-6608
> Project: Maven
> Issue Type: New Feature
> Components: Design, Patterns & Best Practices
> Affects Versions: 3.6.0
> Reporter: chenxiaoyong
> Priority: Major
> Attachments: revision-test.zip
>
>
> we need modify project.version in pom.xml when we merge source code from
> develope branch to master branch in git. it‘s troublesome!
> Why can't project.version in pom.xml be set as a variable?
> for example:
> {code:xml}
> <project ... >
> <modelVersion>4.0.0</modelVersion>
> <groupId>org.example</groupId>
> <artifactId>example</artifactId>
> <version>${project-version}</version>
> <packaging>jar</packaging>
> <properties>
> <project-version>1.0.0-SNAPSHOT</project-version>
> </properties>
> <profiles>
> <profile>
> <!-- snapshot -->
> <id>dev</id>
> <properties>
> <profiles.active>dev</profiles.active>
> <project-version>1.0.0-SNAPSHOT</project-version>
> </properties>
> <activation>
> <activeByDefault>true</activeByDefault>
> </activation>
> </profile>
> <profile>
> <!-- RELEASE -->
> <id>release</id>
> <properties>
> <profiles.active>release</profiles.active>
> <project-version>1.0.0-RELEASE</project-version>
> </properties>
> </profile>
> </profiles>
>
> </project>
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
