There is one major difference here:
* the 'project.version' property is referring to the version elemen of the
project. It is not a "user-created" property and cannot be defined on
command line.
* the 'revision' property is just a property that needs to be defined
(either on command-line or in the properties section of the pom).
However, there is some magic around the 'revision' property as it is one of
few properties allowed to be used in the parent version element. If you,
for example, try to use a property 'foo' there your build will fail.
As the 'revision' property can be defined on command line you cannot deploy
(publish) a pom containing this property as the actual value of the
property could be defined differently in some other build which has a
dependency to your artifact. Coordinates in your published pom must not
change (neither for the artifact itself or for any dependencies). That's
why you need to use flatten-m-p to transform the pom so the values are
hard-coded.
WHen it comes to the project.version property doesn't need to be resolved
in advance as it refers to the version of the project (artifact) itself.
Hence it cannot be altered outside of the project (artifact). (However, it
could be that the flatten-m-p does resolve that as well; I haven't checked.
But there is no technical need to do that.)
/Anders
On Thu, Jan 19, 2023 at 10:48 AM Vilius Šumskas <vilius.sums...@rivile.lt>
wrote:
> I know how standard user-created Maven properties are resolved, and you
> are completely right that there are plenty of information how to configure
> them. However, there is almost no information at what phase and how various
> built-in properties are actually resolved. Including how ${revision} is
> different from ${project.version} and why you have to stick to one of them
> in parent, and another in rest of the POM. Or how these properties are
> affected by inheritence in multi-module project for example. Hence, my
> questions.
>
> --
> Vilius
>
> -----Original Message-----
> From: Anders Hammar <and...@hammar.net>
> Sent: Thursday, January 19, 2023 11:36 AM
> To: Maven Users List <users@maven.apache.org>
> Subject: Re: how to correctly specify Maven child dependency version for CI
>
> It's properties resolution in Maven. There are plenty of web pages
> describing this.
>
> /Anders
>
> On Thu, Jan 19, 2023 at 10:01 AM Vilius Šumskas <vilius.sums...@rivile.lt>
> wrote:
>
> > Can you ellaborate a bit how ${project.version} is resolved? I suppose
> > it is somewhat special parameter?
> >
> > --
> > Vilius
> >
> > -----Original Message-----
> > From: Anders Hammar <and...@hammar.net>
> > Sent: Wednesday, January 18, 2023 8:45 PM
> > To: Maven Users List <users@maven.apache.org>
> > Subject: Re: how to correctly specify Maven child dependency version
> > for CI
> >
> > I believe this is handled by Flatten Maven plugin (during build) and
> > could have been improved in a release after that text was written. If
> > ${revision} is resolved for dependency versions then I guess there is
> > no problem. It's like you hard-coding it. ${project.version} on the
> > other hand will IIRC not be resolved and then handled in the standard
> way by Maven.
> >
> > /Anders
> >
> > On Wed, Jan 18, 2023 at 12:13 AM Vilius Šumskas
> > <vilius.sums...@rivile.lt>
> > wrote:
> >
> > > Hello,
> > >
> > > just wondering if information in
> > > https://maven.apache.org/maven-ci-friendly.html#dependencies still
> > > stands regardng sub-module versions? Specifically this sentence:
> > > „The usual way of defining dependencies and their appropriate
> > > versions has been to use ${project.version} and this has not been
> > > changed.“ and
> > > later:
> > > „If you try to use ${revision} instead of ${project.version} your
> > > build will fail.“
> > >
> > > I’ve just accidently made a project where I have use ${revision}
> > > everywhere, including dependencies between childs themselves, and it
> > > builds without errors. Maybe this was improved in recent Maven
> > > versions and is no longer actual?
> > >
> > > --
> > > Best Regards,
> > >
> > > Vilius Šumskas
> > > Rivile
> > > IT manager
> > >
> > >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
