You are viewing a plain text version of this content. The canonical link for it is here.

Posted to users@maven.apache.org by Eric B <eb...@gmail.com> on 2017/11/14 02:12:21 UTC

Special parameters - sha1

Following a long thread on this list, and a blog by khmarbaise (
http://blog.soebes.de/blog/2017/04/02/maven-pom-files-without-a-version-in-it/),
I'm still a little confused as to exactly what is allowed in the special
version tags for a maven pom.

I know and realize that the 3 allowable tags are:
 - ${revision}
 - ${sha1}
 - ${changelist}

However, from the thread and the blog, it seems that these properties
cannot be dependent on any other properties.

For example, this is fine:
       <version>${revision}-${sha1}</version>
where mvn is called with -Drevision=1.2.3 -Dsha1=1a2b3c4e


However, based on the further docs at
https://maven.apache.org/maven-ci-friendly.html, this design would fail:

<version>${revision}-${sha1}</version>

<properties>
     <sha1>${buildNumber}</sha1>
</properties>


and call it as -Drevision=1.2.3 -DbuildNumber=99999


Is anyone able to shed some light as to why this would be the case?  Why
can a property not be used to compute on of the 3 special vars?

My use case is that I want to supply the build number to all my builds, but
only append it to the version if a specific profile is enabled.  In my
mind, it would be simple - make the sha1 property empty by default, and in
my specific profile, set it to the buildnumber.   But based on my
understanding, this would fail.

Is my only option in that case to design it as:

<version>${artifactVersion}</version>
<properties>
  <artifactVersion>${revision}</artifactVersion>
</properties>

<profile>
  <id>buildNumber</id>
  <properties>
     <artifactVersion>${revision}-${sha1}</artifactVersion>
  </properties>
</profile>


What is the reason for this limitation?  Is there any chance that this
limitation will be removed in the future?

Thanks,

Eric

Re: Special parameters - sha1

Posted by Eric Benzacar <er...@benzacar.ca>.

Thanks for the insight; I guess that's kind of what I was doing with the
sha1/build number.  I would end up with a 5.0.0-1a2b3c4d which would make
it a unique,random number.

I may end up rethinking this though based on some of the insights you
shared.

Thanks,

Eric

On Fri, Nov 17, 2017 at 4:13 PM, Stephen Connolly <
stephen.alan.connolly@gmail.com> wrote:

> On Fri 17 Nov 2017 at 21:07, Stephen Connolly <
> stephen.alan.connolly@gmail.com> wrote:
>
> >
> > On Fri 17 Nov 2017 at 13:57, Eric B <eb...@gmail.com> wrote:
> >
> >> Hi Bernd,
> >>
> >> Thanks for the insight.  I understand what you mean, and to be honest,
> not
> >> entirely sure how to deal with that yet.  At the moment, it isn't a huge
> >> deal for me since my project is fairy self contained.  I have an API
> >> module
> >> which I need to version independently, but other than that, there are no
> >> artifacts produced that are consumed outside of my project... yet.
> >>
> >> But my issue is that I really dont know how to best handle this
> situation.
> >> At the moment, I am forced to build my release branch in snapshot mode
> >> which is aggravating.  I'm on Nexus 3 which doesn't support staging
> repos
> >> yet, and I've already generated at least 20+ builds from this release
> >> branch.  I can't keep rolling my semantic version number each time ...
> My
> >> business stakeholders would have a fit seeing version 5.0.63 being
> >> released
> >> instead of 5.0.0.
> >>
> >
> > Education is the solution...
> >
> > Educate them on what that 3rd digit means and why they want it high not
> low
> >
>
> At one company we used to routinely just add random amounts to the
> build/patch segment just so that stakeholders would be forced to stop
> assuming sequential versions.
>
> Otherwise you end up having to discuss “we need to re-release 5.0.0 because
> of a critical bug” and you never want to reuse a version number... like
> ever.
>
> So the least significant segment should be strictly incremental... does not
> need to be a constant increment.
>
> If the business needs X.Y.Z to be specific values then add another segment
> for the build number
>
>
> >
> >> Are there other recommended processes to use instead? Nexus 2 staging
> >> repos
> >> dealt with all this very neatly, but with that not coming to v3 for at
> >> least 2 more quarters I need to put together a more functional solution.
> >>
> >> Thanks
> >>
> >> Eric
> >>
> >> On Nov 16, 2017 12:50 AM, "Bernd Eckenfels" <ec...@zusammenkunft.net>
> >> wrote:
> >>
> >> > Hello,
> >> >
> >> > If you have a POM with dependencies to other modules which are built
> on
> >> > each change, you typically want to make sure you use those updated
> >> > dependencies when you compile your projects.
> >> >
> >> > With regularly changing version numbers and without using SNAPSHOT
> >> > dependencies you will need to find a solution for this. You could use
> >> > version ranges, but then you are not much different then using
> SNAPSHOT
> >> > builds. This is one of the main reasons why we are doing manual
> >> releases -
> >> > and managing the dependency versions by hand.
> >> >
> >> > Gruss
> >> > Bernd
> >> > --
> >> > http://bernd.eckenfels.net
> >> > ________________________________
> >> > From: Eric Benzacar <er...@benzacar.ca>
> >> > Sent: Thursday, November 16, 2017 5:05:45 AM
> >> > To: Maven Users List
> >> > Cc: info@soebes.de
> >> > Subject: Re: Special <version> parameters - sha1
> >> >
> >> > I'm not sure what you mean when you say:
> >> >
> >> > "How are you planning to deal with the changed version numbers of
> >> > dependencies?"
> >> >
> >> > At which stage are you referring to?  Which dependencies with changed
> >> > version numbers?
> >> >
> >> > Thanks,
> >> >
> >> > Eric
> >> >
> >> > On Wed, Nov 15, 2017 at 1:11 AM, Bernd Eckenfels <
> >> ecki@zusammenkunft.net>
> >> > wrote:
> >> >
> >> > > You have to remember that POMs are also the model to describe
> >> artifacts,
> >> > > that why you should stay clear of profiles (especially if the
> >> influence
> >> > > artifact coordinates).
> >> > >
> >> > > Personally I have good experience with actually releasing things,
> but
> >> if
> >> > > you want to keep the build identifier, then I would agree, that
> >> handling
> >> > > this in the build job is probably the best. You can have even two
> >> > > Parameterized jobs.
> >> > >
> >> > > How are you planning to deal with the changed version numbers of
> >> > > dependencies?
> >> > >
> >> > > Gruss
> >> > > Bernd
> >> > > --
> >> > > http://bernd.eckenfels.net
> >> > > ________________________________
> >> > > From: Eric B <eb...@gmail.com>
> >> > > Sent: Wednesday, November 15, 2017 4:30:06 AM
> >> > > To: info@soebes.de; Maven Users List
> >> > > Subject: Re: Special <version> parameters - sha1
> >> > >
> >> > > Hi,
> >> > >
> >> > > Thanks for the additional insight.  I think I understand better now
> >> how
> >> > > this works.   I'll try to explain my use case, and perhaps someone
> can
> >> > > provide some ideas for best practices.
> >> > >
> >> > > I started a pom refactoring because I wanted to add the
> >> enforcer-plugin
> >> > for
> >> > > a release candidate to ensure there are no SNAPSHOTs in the pom.
> For
> >> our
> >> > > dev purposes, we have defined that anything in a release/ branch
> >> > (Gitflow)
> >> > > is a release candidate.  Anything in the dev/ branch can be a
> >> SNAPSHOT.
> >> > > Additionally, we use semantic versioning, so our versions read
> 4.7.0,
> >> > > 4.7.1, 5.0.0, 5.1.0, etc...  Consequently, each build coming from a
> >> > release
> >> > > branch needs to have a unique version.  I don't want to update the
> >> > version
> >> > > number for each build, so each build has to have a build number or
> >> sha1
> >> > > attached to the version.
> >> > >
> >> > > My build pipeline is very basic for the moment; it's a simple
> Jenkins
> >> > > freestyle job (not a pipeline job yet).  Ideally, I'm trying to keep
> >> it
> >> > as
> >> > > simple as possible and always pass the same parameters to the maven
> >> build
> >> > > process (to make it easier for others to understand).
> >> > >
> >> > > I'm passing the following parameters to the maven build:
> >> > >  -DbranchType=release
> >> > >  -DbuildNumber=<jenkins build number>
> >> > >
> >> > > maven.config:
> >> > > -Drevision=5.0.0
> >> > >
> >> > >
> >> > >
> >> > > My thought process is I could do the following - for the normal use
> >> case
> >> > > (ie: dev branch):
> >> > > <version>${revision}${changelist}</version>
> >> > > <properties>
> >> > >   <changelist>-SNAPSHOT</changelist>
> >> > > </properties>
> >> > >
> >> > >
> >> > > For a release:
> >> > > <profile>
> >> > >   <id>relelase</id>
> >> > >   <activation>
> >> > >     <property>
> >> > >        <name>branchType</name>
> >> > >        <value>release</value>
> >> > >     </property>
> >> > >   </activation>
> >> > >    <properties>
> >> > >       <changelist></changelist>
> >> > >       <sha1>${buildNumber}</sha1>
> >> > >    </properties>
> >> > >     <!-- enable enforcer plugin to prevent SNAPSHOTs etc -->
> >> > > </profile>
> >> > >
> >> > >
> >> > > But now I see that won't work.  So I need to pass the buildnumber on
> >> the
> >> > > command line as a SHA1 parameter.  But if I do that in this design,
> >> the
> >> > > SNAPSHOT will also include the SHA1 which is not what I want.
> >> > >
> >> > > So from what I can see, the only option is to modify the parameters
> on
> >> > the
> >> > > command line.  Which means I have to add some additional logic to my
> >> > > Jenkins build.  This would be much easier if I had a Pipeline build
> >> but I
> >> > > don't at the moment.  I was just looking to put the intelligence in
> >> the
> >> > pom
> >> > > so that anyone could easily read & understand it.
> >> > >
> >> > > Any suggestions or recommendations would be greatly appreciated.  Is
> >> > there
> >> > > anyway to do this in the pom itself?
> >> > >
> >> > > Thanks,
> >> > >
> >> > > Eric
> >> > >
> >> > > On Tue, Nov 14, 2017 at 8:42 AM, Karl Heinz Marbaise <
> >> khmarbaise@gmx.de>
> >> > > wrote:
> >> > >
> >> > > > Hi,
> >> > > >
> >> > > >
> >> > > > I will give some more details cause I have created the docs /
> >> > > > implementation and you mentioned my blog ;-)..
> >> > > >
> >> > > >
> >> > > > On 14/11/17 03:12, Eric B wrote:
> >> > > >
> >> > > >> Following a long thread on this list, and a blog by khmarbaise (
> >> > > >> http://blog.soebes.de/blog/2017/04/02/maven-pom-files-withou
> >> > > >> t-a-version-in-it/),
> >> > > >> I'm still a little confused as to exactly what is allowed in the
> >> > special
> >> > > >> version tags for a maven pom.
> >> > > >>
> >> > > >> I know and realize that the 3 allowable tags are:
> >> > > >>   - ${revision}
> >> > > >>   - ${sha1}
> >> > > >>   - ${changelist}
> >> > > >>
> >> > > >> However, from the thread and the blog, it seems that these
> >> properties
> >> > > >> cannot be dependent on any other properties.
> >> > > >>
> >> > > >
> >> > > > Correct.
> >> > > >
> >> > > >>
> >> > > >> For example, this is fine:
> >> > > >>         <version>${revision}-${sha1}</version>
> >> > > >> where mvn is called with -Drevision=1.2.3 -Dsha1=1a2b3c4e
> >> > > >>
> >> > > >>
> >> > > >> However, based on the further docs at
> >> > > >> https://maven.apache.org/maven-ci-friendly.html, this design
> would
> >> > > fail:
> >> > > >>
> >> > > >
> >> > > > which is not mentioned in the docs...
> >> > > >
> >> > > >
> >> > > >> <version>${revision}-${sha1}</version>
> >> > > >>
> >> > > >> <properties>
> >> > > >>       <sha1>${buildNumber}</sha1>
> >> > > >> </properties>
> >> > > >>
> >> > > >>
> >> > > >> and call it as -Drevision=1.2.3 -DbuildNumber=99999
> >> > > >>
> >> > > >
> >> > > > The problem is simply that buildNumber is not correctly
> overwritten
> >> > from
> >> > > > command and not correctly handled duing the model reading /
> >> > interpolation
> >> > > > at the correct time within Maven Core at the moment...
> >> > > >
> >> > > > At the moment this is only implemented for those special three
> >> > > > properties...which already has performance impacts...which is
> also a
> >> > > reason
> >> > > > not making that possible for all kind of properties...at the
> >> moment...
> >> > > >
> >> > > >
> >> > > >>
> >> > > >> Is anyone able to shed some light as to why this would be the
> case?
> >> > Why
> >> > > >> can a property not be used to compute on of the 3 special vars?
> >> > > >>
> >> > > >> My use case is that I want to supply the build number to all my
> >> > builds,
> >> > > >> but
> >> > > >> only append it to the version if a specific profile is enabled.
> >> In my
> >> > > >> mind, it would be simple - make the sha1 property empty by
> default,
> >> > and
> >> > > in
> >> > > >> my specific profile, set it to the buildnumber.   But based on my
> >> > > >> understanding, this would fail.
> >> > > >>
> >> > > >> Is my only option in that case to design it as:
> >> > > >>
> >> > > >> <version>${artifactVersion}</version>
> >> > > >> <properties>
> >> > > >>    <artifactVersion>${revision}</artifactVersion>
> >> > > >> </properties>
> >> > > >>
> >> > > >> <profile>
> >> > > >>    <id>buildNumber</id>
> >> > > >>    <properties>
> >> > > >>       <artifactVersion>${revision}-${sha1}</artifactVersion>
> >> > > >>    </properties>
> >> > > >> </profile>
> >> > > >>
> >> > > >>
> >> > > >> What is the reason for this limitation?  Is there any chance that
> >> this
> >> > > >> limitation will be removed in the future?
> >> > > >>
> >> > > >
> >> > > > The question is why do you need a profile for this? You can define
> >> > > > defaults in .mvn/maven.config ...and during a CI build you can
> give
> >> > other
> >> > > > information via command line ?
> >> > > >
> >> > > > I don't see the need for a profile ? Maybe you can elaborate a
> >> little
> >> > bit
> >> > > > more what the real problem is ? ...
> >> > > >
> >> > > >
> >> > > > Kind regards
> >> > > > Karl Heinz Marbaise
> >> > > >
> >> > >
> >> >
> >>
> > --
> > Sent from my phone
> >
> --
> Sent from my phone
>

Re: Special parameters - sha1

Posted by Stephen Connolly <st...@gmail.com>.

On Fri 17 Nov 2017 at 21:07, Stephen Connolly <
stephen.alan.connolly@gmail.com> wrote:

>
> On Fri 17 Nov 2017 at 13:57, Eric B <eb...@gmail.com> wrote:
>
>> Hi Bernd,
>>
>> Thanks for the insight.  I understand what you mean, and to be honest, not
>> entirely sure how to deal with that yet.  At the moment, it isn't a huge
>> deal for me since my project is fairy self contained.  I have an API
>> module
>> which I need to version independently, but other than that, there are no
>> artifacts produced that are consumed outside of my project... yet.
>>
>> But my issue is that I really dont know how to best handle this situation.
>> At the moment, I am forced to build my release branch in snapshot mode
>> which is aggravating.  I'm on Nexus 3 which doesn't support staging repos
>> yet, and I've already generated at least 20+ builds from this release
>> branch.  I can't keep rolling my semantic version number each time ... My
>> business stakeholders would have a fit seeing version 5.0.63 being
>> released
>> instead of 5.0.0.
>>
>
> Education is the solution...
>
> Educate them on what that 3rd digit means and why they want it high not low
>

At one company we used to routinely just add random amounts to the
build/patch segment just so that stakeholders would be forced to stop
assuming sequential versions.

Otherwise you end up having to discuss “we need to re-release 5.0.0 because
of a critical bug” and you never want to reuse a version number... like
ever.

So the least significant segment should be strictly incremental... does not
need to be a constant increment.

If the business needs X.Y.Z to be specific values then add another segment
for the build number


>
>> Are there other recommended processes to use instead? Nexus 2 staging
>> repos
>> dealt with all this very neatly, but with that not coming to v3 for at
>> least 2 more quarters I need to put together a more functional solution.
>>
>> Thanks
>>
>> Eric
>>
>> On Nov 16, 2017 12:50 AM, "Bernd Eckenfels" <ec...@zusammenkunft.net>
>> wrote:
>>
>> > Hello,
>> >
>> > If you have a POM with dependencies to other modules which are built on
>> > each change, you typically want to make sure you use those updated
>> > dependencies when you compile your projects.
>> >
>> > With regularly changing version numbers and without using SNAPSHOT
>> > dependencies you will need to find a solution for this. You could use
>> > version ranges, but then you are not much different then using SNAPSHOT
>> > builds. This is one of the main reasons why we are doing manual
>> releases -
>> > and managing the dependency versions by hand.
>> >
>> > Gruss
>> > Bernd
>> > --
>> > http://bernd.eckenfels.net
>> > ________________________________
>> > From: Eric Benzacar <er...@benzacar.ca>
>> > Sent: Thursday, November 16, 2017 5:05:45 AM
>> > To: Maven Users List
>> > Cc: info@soebes.de
>> > Subject: Re: Special <version> parameters - sha1
>> >
>> > I'm not sure what you mean when you say:
>> >
>> > "How are you planning to deal with the changed version numbers of
>> > dependencies?"
>> >
>> > At which stage are you referring to?  Which dependencies with changed
>> > version numbers?
>> >
>> > Thanks,
>> >
>> > Eric
>> >
>> > On Wed, Nov 15, 2017 at 1:11 AM, Bernd Eckenfels <
>> ecki@zusammenkunft.net>
>> > wrote:
>> >
>> > > You have to remember that POMs are also the model to describe
>> artifacts,
>> > > that why you should stay clear of profiles (especially if the
>> influence
>> > > artifact coordinates).
>> > >
>> > > Personally I have good experience with actually releasing things, but
>> if
>> > > you want to keep the build identifier, then I would agree, that
>> handling
>> > > this in the build job is probably the best. You can have even two
>> > > Parameterized jobs.
>> > >
>> > > How are you planning to deal with the changed version numbers of
>> > > dependencies?
>> > >
>> > > Gruss
>> > > Bernd
>> > > --
>> > > http://bernd.eckenfels.net
>> > > ________________________________
>> > > From: Eric B <eb...@gmail.com>
>> > > Sent: Wednesday, November 15, 2017 4:30:06 AM
>> > > To: info@soebes.de; Maven Users List
>> > > Subject: Re: Special <version> parameters - sha1
>> > >
>> > > Hi,
>> > >
>> > > Thanks for the additional insight.  I think I understand better now
>> how
>> > > this works.   I'll try to explain my use case, and perhaps someone can
>> > > provide some ideas for best practices.
>> > >
>> > > I started a pom refactoring because I wanted to add the
>> enforcer-plugin
>> > for
>> > > a release candidate to ensure there are no SNAPSHOTs in the pom.  For
>> our
>> > > dev purposes, we have defined that anything in a release/ branch
>> > (Gitflow)
>> > > is a release candidate.  Anything in the dev/ branch can be a
>> SNAPSHOT.
>> > > Additionally, we use semantic versioning, so our versions read 4.7.0,
>> > > 4.7.1, 5.0.0, 5.1.0, etc...  Consequently, each build coming from a
>> > release
>> > > branch needs to have a unique version.  I don't want to update the
>> > version
>> > > number for each build, so each build has to have a build number or
>> sha1
>> > > attached to the version.
>> > >
>> > > My build pipeline is very basic for the moment; it's a simple Jenkins
>> > > freestyle job (not a pipeline job yet).  Ideally, I'm trying to keep
>> it
>> > as
>> > > simple as possible and always pass the same parameters to the maven
>> build
>> > > process (to make it easier for others to understand).
>> > >
>> > > I'm passing the following parameters to the maven build:
>> > >  -DbranchType=release
>> > >  -DbuildNumber=<jenkins build number>
>> > >
>> > > maven.config:
>> > > -Drevision=5.0.0
>> > >
>> > >
>> > >
>> > > My thought process is I could do the following - for the normal use
>> case
>> > > (ie: dev branch):
>> > > <version>${revision}${changelist}</version>
>> > > <properties>
>> > >   <changelist>-SNAPSHOT</changelist>
>> > > </properties>
>> > >
>> > >
>> > > For a release:
>> > > <profile>
>> > >   <id>relelase</id>
>> > >   <activation>
>> > >     <property>
>> > >        <name>branchType</name>
>> > >        <value>release</value>
>> > >     </property>
>> > >   </activation>
>> > >    <properties>
>> > >       <changelist></changelist>
>> > >       <sha1>${buildNumber}</sha1>
>> > >    </properties>
>> > >     <!-- enable enforcer plugin to prevent SNAPSHOTs etc -->
>> > > </profile>
>> > >
>> > >
>> > > But now I see that won't work.  So I need to pass the buildnumber on
>> the
>> > > command line as a SHA1 parameter.  But if I do that in this design,
>> the
>> > > SNAPSHOT will also include the SHA1 which is not what I want.
>> > >
>> > > So from what I can see, the only option is to modify the parameters on
>> > the
>> > > command line.  Which means I have to add some additional logic to my
>> > > Jenkins build.  This would be much easier if I had a Pipeline build
>> but I
>> > > don't at the moment.  I was just looking to put the intelligence in
>> the
>> > pom
>> > > so that anyone could easily read & understand it.
>> > >
>> > > Any suggestions or recommendations would be greatly appreciated.  Is
>> > there
>> > > anyway to do this in the pom itself?
>> > >
>> > > Thanks,
>> > >
>> > > Eric
>> > >
>> > > On Tue, Nov 14, 2017 at 8:42 AM, Karl Heinz Marbaise <
>> khmarbaise@gmx.de>
>> > > wrote:
>> > >
>> > > > Hi,
>> > > >
>> > > >
>> > > > I will give some more details cause I have created the docs /
>> > > > implementation and you mentioned my blog ;-)..
>> > > >
>> > > >
>> > > > On 14/11/17 03:12, Eric B wrote:
>> > > >
>> > > >> Following a long thread on this list, and a blog by khmarbaise (
>> > > >> http://blog.soebes.de/blog/2017/04/02/maven-pom-files-withou
>> > > >> t-a-version-in-it/),
>> > > >> I'm still a little confused as to exactly what is allowed in the
>> > special
>> > > >> version tags for a maven pom.
>> > > >>
>> > > >> I know and realize that the 3 allowable tags are:
>> > > >>   - ${revision}
>> > > >>   - ${sha1}
>> > > >>   - ${changelist}
>> > > >>
>> > > >> However, from the thread and the blog, it seems that these
>> properties
>> > > >> cannot be dependent on any other properties.
>> > > >>
>> > > >
>> > > > Correct.
>> > > >
>> > > >>
>> > > >> For example, this is fine:
>> > > >>         <version>${revision}-${sha1}</version>
>> > > >> where mvn is called with -Drevision=1.2.3 -Dsha1=1a2b3c4e
>> > > >>
>> > > >>
>> > > >> However, based on the further docs at
>> > > >> https://maven.apache.org/maven-ci-friendly.html, this design would
>> > > fail:
>> > > >>
>> > > >
>> > > > which is not mentioned in the docs...
>> > > >
>> > > >
>> > > >> <version>${revision}-${sha1}</version>
>> > > >>
>> > > >> <properties>
>> > > >>       <sha1>${buildNumber}</sha1>
>> > > >> </properties>
>> > > >>
>> > > >>
>> > > >> and call it as -Drevision=1.2.3 -DbuildNumber=99999
>> > > >>
>> > > >
>> > > > The problem is simply that buildNumber is not correctly overwritten
>> > from
>> > > > command and not correctly handled duing the model reading /
>> > interpolation
>> > > > at the correct time within Maven Core at the moment...
>> > > >
>> > > > At the moment this is only implemented for those special three
>> > > > properties...which already has performance impacts...which is also a
>> > > reason
>> > > > not making that possible for all kind of properties...at the
>> moment...
>> > > >
>> > > >
>> > > >>
>> > > >> Is anyone able to shed some light as to why this would be the case?
>> > Why
>> > > >> can a property not be used to compute on of the 3 special vars?
>> > > >>
>> > > >> My use case is that I want to supply the build number to all my
>> > builds,
>> > > >> but
>> > > >> only append it to the version if a specific profile is enabled.
>> In my
>> > > >> mind, it would be simple - make the sha1 property empty by default,
>> > and
>> > > in
>> > > >> my specific profile, set it to the buildnumber.   But based on my
>> > > >> understanding, this would fail.
>> > > >>
>> > > >> Is my only option in that case to design it as:
>> > > >>
>> > > >> <version>${artifactVersion}</version>
>> > > >> <properties>
>> > > >>    <artifactVersion>${revision}</artifactVersion>
>> > > >> </properties>
>> > > >>
>> > > >> <profile>
>> > > >>    <id>buildNumber</id>
>> > > >>    <properties>
>> > > >>       <artifactVersion>${revision}-${sha1}</artifactVersion>
>> > > >>    </properties>
>> > > >> </profile>
>> > > >>
>> > > >>
>> > > >> What is the reason for this limitation?  Is there any chance that
>> this
>> > > >> limitation will be removed in the future?
>> > > >>
>> > > >
>> > > > The question is why do you need a profile for this? You can define
>> > > > defaults in .mvn/maven.config ...and during a CI build you can give
>> > other
>> > > > information via command line ?
>> > > >
>> > > > I don't see the need for a profile ? Maybe you can elaborate a
>> little
>> > bit
>> > > > more what the real problem is ? ...
>> > > >
>> > > >
>> > > > Kind regards
>> > > > Karl Heinz Marbaise
>> > > >
>> > >
>> >
>>
> --
> Sent from my phone
>
-- 
Sent from my phone

Re: Special parameters - sha1

Posted by Stephen Connolly <st...@gmail.com>.

On Fri 17 Nov 2017 at 13:57, Eric B <eb...@gmail.com> wrote:

> Hi Bernd,
>
> Thanks for the insight.  I understand what you mean, and to be honest, not
> entirely sure how to deal with that yet.  At the moment, it isn't a huge
> deal for me since my project is fairy self contained.  I have an API module
> which I need to version independently, but other than that, there are no
> artifacts produced that are consumed outside of my project... yet.
>
> But my issue is that I really dont know how to best handle this situation.
> At the moment, I am forced to build my release branch in snapshot mode
> which is aggravating.  I'm on Nexus 3 which doesn't support staging repos
> yet, and I've already generated at least 20+ builds from this release
> branch.  I can't keep rolling my semantic version number each time ... My
> business stakeholders would have a fit seeing version 5.0.63 being released
> instead of 5.0.0.
>

Education is the solution...

Educate them on what that 3rd digit means and why they want it high not low


> Are there other recommended processes to use instead? Nexus 2 staging repos
> dealt with all this very neatly, but with that not coming to v3 for at
> least 2 more quarters I need to put together a more functional solution.
>
> Thanks
>
> Eric
>
> On Nov 16, 2017 12:50 AM, "Bernd Eckenfels" <ec...@zusammenkunft.net>
> wrote:
>
> > Hello,
> >
> > If you have a POM with dependencies to other modules which are built on
> > each change, you typically want to make sure you use those updated
> > dependencies when you compile your projects.
> >
> > With regularly changing version numbers and without using SNAPSHOT
> > dependencies you will need to find a solution for this. You could use
> > version ranges, but then you are not much different then using SNAPSHOT
> > builds. This is one of the main reasons why we are doing manual releases
> -
> > and managing the dependency versions by hand.
> >
> > Gruss
> > Bernd
> > --
> > http://bernd.eckenfels.net
> > ________________________________
> > From: Eric Benzacar <er...@benzacar.ca>
> > Sent: Thursday, November 16, 2017 5:05:45 AM
> > To: Maven Users List
> > Cc: info@soebes.de
> > Subject: Re: Special <version> parameters - sha1
> >
> > I'm not sure what you mean when you say:
> >
> > "How are you planning to deal with the changed version numbers of
> > dependencies?"
> >
> > At which stage are you referring to?  Which dependencies with changed
> > version numbers?
> >
> > Thanks,
> >
> > Eric
> >
> > On Wed, Nov 15, 2017 at 1:11 AM, Bernd Eckenfels <ecki@zusammenkunft.net
> >
> > wrote:
> >
> > > You have to remember that POMs are also the model to describe
> artifacts,
> > > that why you should stay clear of profiles (especially if the influence
> > > artifact coordinates).
> > >
> > > Personally I have good experience with actually releasing things, but
> if
> > > you want to keep the build identifier, then I would agree, that
> handling
> > > this in the build job is probably the best. You can have even two
> > > Parameterized jobs.
> > >
> > > How are you planning to deal with the changed version numbers of
> > > dependencies?
> > >
> > > Gruss
> > > Bernd
> > > --
> > > http://bernd.eckenfels.net
> > > ________________________________
> > > From: Eric B <eb...@gmail.com>
> > > Sent: Wednesday, November 15, 2017 4:30:06 AM
> > > To: info@soebes.de; Maven Users List
> > > Subject: Re: Special <version> parameters - sha1
> > >
> > > Hi,
> > >
> > > Thanks for the additional insight.  I think I understand better now how
> > > this works.   I'll try to explain my use case, and perhaps someone can
> > > provide some ideas for best practices.
> > >
> > > I started a pom refactoring because I wanted to add the enforcer-plugin
> > for
> > > a release candidate to ensure there are no SNAPSHOTs in the pom.  For
> our
> > > dev purposes, we have defined that anything in a release/ branch
> > (Gitflow)
> > > is a release candidate.  Anything in the dev/ branch can be a SNAPSHOT.
> > > Additionally, we use semantic versioning, so our versions read 4.7.0,
> > > 4.7.1, 5.0.0, 5.1.0, etc...  Consequently, each build coming from a
> > release
> > > branch needs to have a unique version.  I don't want to update the
> > version
> > > number for each build, so each build has to have a build number or sha1
> > > attached to the version.
> > >
> > > My build pipeline is very basic for the moment; it's a simple Jenkins
> > > freestyle job (not a pipeline job yet).  Ideally, I'm trying to keep it
> > as
> > > simple as possible and always pass the same parameters to the maven
> build
> > > process (to make it easier for others to understand).
> > >
> > > I'm passing the following parameters to the maven build:
> > >  -DbranchType=release
> > >  -DbuildNumber=<jenkins build number>
> > >
> > > maven.config:
> > > -Drevision=5.0.0
> > >
> > >
> > >
> > > My thought process is I could do the following - for the normal use
> case
> > > (ie: dev branch):
> > > <version>${revision}${changelist}</version>
> > > <properties>
> > >   <changelist>-SNAPSHOT</changelist>
> > > </properties>
> > >
> > >
> > > For a release:
> > > <profile>
> > >   <id>relelase</id>
> > >   <activation>
> > >     <property>
> > >        <name>branchType</name>
> > >        <value>release</value>
> > >     </property>
> > >   </activation>
> > >    <properties>
> > >       <changelist></changelist>
> > >       <sha1>${buildNumber}</sha1>
> > >    </properties>
> > >     <!-- enable enforcer plugin to prevent SNAPSHOTs etc -->
> > > </profile>
> > >
> > >
> > > But now I see that won't work.  So I need to pass the buildnumber on
> the
> > > command line as a SHA1 parameter.  But if I do that in this design, the
> > > SNAPSHOT will also include the SHA1 which is not what I want.
> > >
> > > So from what I can see, the only option is to modify the parameters on
> > the
> > > command line.  Which means I have to add some additional logic to my
> > > Jenkins build.  This would be much easier if I had a Pipeline build
> but I
> > > don't at the moment.  I was just looking to put the intelligence in the
> > pom
> > > so that anyone could easily read & understand it.
> > >
> > > Any suggestions or recommendations would be greatly appreciated.  Is
> > there
> > > anyway to do this in the pom itself?
> > >
> > > Thanks,
> > >
> > > Eric
> > >
> > > On Tue, Nov 14, 2017 at 8:42 AM, Karl Heinz Marbaise <
> khmarbaise@gmx.de>
> > > wrote:
> > >
> > > > Hi,
> > > >
> > > >
> > > > I will give some more details cause I have created the docs /
> > > > implementation and you mentioned my blog ;-)..
> > > >
> > > >
> > > > On 14/11/17 03:12, Eric B wrote:
> > > >
> > > >> Following a long thread on this list, and a blog by khmarbaise (
> > > >> http://blog.soebes.de/blog/2017/04/02/maven-pom-files-withou
> > > >> t-a-version-in-it/),
> > > >> I'm still a little confused as to exactly what is allowed in the
> > special
> > > >> version tags for a maven pom.
> > > >>
> > > >> I know and realize that the 3 allowable tags are:
> > > >>   - ${revision}
> > > >>   - ${sha1}
> > > >>   - ${changelist}
> > > >>
> > > >> However, from the thread and the blog, it seems that these
> properties
> > > >> cannot be dependent on any other properties.
> > > >>
> > > >
> > > > Correct.
> > > >
> > > >>
> > > >> For example, this is fine:
> > > >>         <version>${revision}-${sha1}</version>
> > > >> where mvn is called with -Drevision=1.2.3 -Dsha1=1a2b3c4e
> > > >>
> > > >>
> > > >> However, based on the further docs at
> > > >> https://maven.apache.org/maven-ci-friendly.html, this design would
> > > fail:
> > > >>
> > > >
> > > > which is not mentioned in the docs...
> > > >
> > > >
> > > >> <version>${revision}-${sha1}</version>
> > > >>
> > > >> <properties>
> > > >>       <sha1>${buildNumber}</sha1>
> > > >> </properties>
> > > >>
> > > >>
> > > >> and call it as -Drevision=1.2.3 -DbuildNumber=99999
> > > >>
> > > >
> > > > The problem is simply that buildNumber is not correctly overwritten
> > from
> > > > command and not correctly handled duing the model reading /
> > interpolation
> > > > at the correct time within Maven Core at the moment...
> > > >
> > > > At the moment this is only implemented for those special three
> > > > properties...which already has performance impacts...which is also a
> > > reason
> > > > not making that possible for all kind of properties...at the
> moment...
> > > >
> > > >
> > > >>
> > > >> Is anyone able to shed some light as to why this would be the case?
> > Why
> > > >> can a property not be used to compute on of the 3 special vars?
> > > >>
> > > >> My use case is that I want to supply the build number to all my
> > builds,
> > > >> but
> > > >> only append it to the version if a specific profile is enabled.  In
> my
> > > >> mind, it would be simple - make the sha1 property empty by default,
> > and
> > > in
> > > >> my specific profile, set it to the buildnumber.   But based on my
> > > >> understanding, this would fail.
> > > >>
> > > >> Is my only option in that case to design it as:
> > > >>
> > > >> <version>${artifactVersion}</version>
> > > >> <properties>
> > > >>    <artifactVersion>${revision}</artifactVersion>
> > > >> </properties>
> > > >>
> > > >> <profile>
> > > >>    <id>buildNumber</id>
> > > >>    <properties>
> > > >>       <artifactVersion>${revision}-${sha1}</artifactVersion>
> > > >>    </properties>
> > > >> </profile>
> > > >>
> > > >>
> > > >> What is the reason for this limitation?  Is there any chance that
> this
> > > >> limitation will be removed in the future?
> > > >>
> > > >
> > > > The question is why do you need a profile for this? You can define
> > > > defaults in .mvn/maven.config ...and during a CI build you can give
> > other
> > > > information via command line ?
> > > >
> > > > I don't see the need for a profile ? Maybe you can elaborate a little
> > bit
> > > > more what the real problem is ? ...
> > > >
> > > >
> > > > Kind regards
> > > > Karl Heinz Marbaise
> > > >
> > >
> >
>
-- 
Sent from my phone

Re: Special parameters - sha1

Posted by Eric B <eb...@gmail.com>.

Hi Bernd,

Thanks for the insight.  I understand what you mean, and to be honest, not
entirely sure how to deal with that yet.  At the moment, it isn't a huge
deal for me since my project is fairy self contained.  I have an API module
which I need to version independently, but other than that, there are no
artifacts produced that are consumed outside of my project... yet.

But my issue is that I really dont know how to best handle this situation.
At the moment, I am forced to build my release branch in snapshot mode
which is aggravating.  I'm on Nexus 3 which doesn't support staging repos
yet, and I've already generated at least 20+ builds from this release
branch.  I can't keep rolling my semantic version number each time ... My
business stakeholders would have a fit seeing version 5.0.63 being released
instead of 5.0.0.

Are there other recommended processes to use instead? Nexus 2 staging repos
dealt with all this very neatly, but with that not coming to v3 for at
least 2 more quarters I need to put together a more functional solution.

Thanks

Eric

On Nov 16, 2017 12:50 AM, "Bernd Eckenfels" <ec...@zusammenkunft.net> wrote:

> Hello,
>
> If you have a POM with dependencies to other modules which are built on
> each change, you typically want to make sure you use those updated
> dependencies when you compile your projects.
>
> With regularly changing version numbers and without using SNAPSHOT
> dependencies you will need to find a solution for this. You could use
> version ranges, but then you are not much different then using SNAPSHOT
> builds. This is one of the main reasons why we are doing manual releases -
> and managing the dependency versions by hand.
>
> Gruss
> Bernd
> --
> http://bernd.eckenfels.net
> ________________________________
> From: Eric Benzacar <er...@benzacar.ca>
> Sent: Thursday, November 16, 2017 5:05:45 AM
> To: Maven Users List
> Cc: info@soebes.de
> Subject: Re: Special <version> parameters - sha1
>
> I'm not sure what you mean when you say:
>
> "How are you planning to deal with the changed version numbers of
> dependencies?"
>
> At which stage are you referring to?  Which dependencies with changed
> version numbers?
>
> Thanks,
>
> Eric
>
> On Wed, Nov 15, 2017 at 1:11 AM, Bernd Eckenfels <ec...@zusammenkunft.net>
> wrote:
>
> > You have to remember that POMs are also the model to describe artifacts,
> > that why you should stay clear of profiles (especially if the influence
> > artifact coordinates).
> >
> > Personally I have good experience with actually releasing things, but if
> > you want to keep the build identifier, then I would agree, that handling
> > this in the build job is probably the best. You can have even two
> > Parameterized jobs.
> >
> > How are you planning to deal with the changed version numbers of
> > dependencies?
> >
> > Gruss
> > Bernd
> > --
> > http://bernd.eckenfels.net
> > ________________________________
> > From: Eric B <eb...@gmail.com>
> > Sent: Wednesday, November 15, 2017 4:30:06 AM
> > To: info@soebes.de; Maven Users List
> > Subject: Re: Special <version> parameters - sha1
> >
> > Hi,
> >
> > Thanks for the additional insight.  I think I understand better now how
> > this works.   I'll try to explain my use case, and perhaps someone can
> > provide some ideas for best practices.
> >
> > I started a pom refactoring because I wanted to add the enforcer-plugin
> for
> > a release candidate to ensure there are no SNAPSHOTs in the pom.  For our
> > dev purposes, we have defined that anything in a release/ branch
> (Gitflow)
> > is a release candidate.  Anything in the dev/ branch can be a SNAPSHOT.
> > Additionally, we use semantic versioning, so our versions read 4.7.0,
> > 4.7.1, 5.0.0, 5.1.0, etc...  Consequently, each build coming from a
> release
> > branch needs to have a unique version.  I don't want to update the
> version
> > number for each build, so each build has to have a build number or sha1
> > attached to the version.
> >
> > My build pipeline is very basic for the moment; it's a simple Jenkins
> > freestyle job (not a pipeline job yet).  Ideally, I'm trying to keep it
> as
> > simple as possible and always pass the same parameters to the maven build
> > process (to make it easier for others to understand).
> >
> > I'm passing the following parameters to the maven build:
> >  -DbranchType=release
> >  -DbuildNumber=<jenkins build number>
> >
> > maven.config:
> > -Drevision=5.0.0
> >
> >
> >
> > My thought process is I could do the following - for the normal use case
> > (ie: dev branch):
> > <version>${revision}${changelist}</version>
> > <properties>
> >   <changelist>-SNAPSHOT</changelist>
> > </properties>
> >
> >
> > For a release:
> > <profile>
> >   <id>relelase</id>
> >   <activation>
> >     <property>
> >        <name>branchType</name>
> >        <value>release</value>
> >     </property>
> >   </activation>
> >    <properties>
> >       <changelist></changelist>
> >       <sha1>${buildNumber}</sha1>
> >    </properties>
> >     <!-- enable enforcer plugin to prevent SNAPSHOTs etc -->
> > </profile>
> >
> >
> > But now I see that won't work.  So I need to pass the buildnumber on the
> > command line as a SHA1 parameter.  But if I do that in this design, the
> > SNAPSHOT will also include the SHA1 which is not what I want.
> >
> > So from what I can see, the only option is to modify the parameters on
> the
> > command line.  Which means I have to add some additional logic to my
> > Jenkins build.  This would be much easier if I had a Pipeline build but I
> > don't at the moment.  I was just looking to put the intelligence in the
> pom
> > so that anyone could easily read & understand it.
> >
> > Any suggestions or recommendations would be greatly appreciated.  Is
> there
> > anyway to do this in the pom itself?
> >
> > Thanks,
> >
> > Eric
> >
> > On Tue, Nov 14, 2017 at 8:42 AM, Karl Heinz Marbaise <kh...@gmx.de>
> > wrote:
> >
> > > Hi,
> > >
> > >
> > > I will give some more details cause I have created the docs /
> > > implementation and you mentioned my blog ;-)..
> > >
> > >
> > > On 14/11/17 03:12, Eric B wrote:
> > >
> > >> Following a long thread on this list, and a blog by khmarbaise (
> > >> http://blog.soebes.de/blog/2017/04/02/maven-pom-files-withou
> > >> t-a-version-in-it/),
> > >> I'm still a little confused as to exactly what is allowed in the
> special
> > >> version tags for a maven pom.
> > >>
> > >> I know and realize that the 3 allowable tags are:
> > >>   - ${revision}
> > >>   - ${sha1}
> > >>   - ${changelist}
> > >>
> > >> However, from the thread and the blog, it seems that these properties
> > >> cannot be dependent on any other properties.
> > >>
> > >
> > > Correct.
> > >
> > >>
> > >> For example, this is fine:
> > >>         <version>${revision}-${sha1}</version>
> > >> where mvn is called with -Drevision=1.2.3 -Dsha1=1a2b3c4e
> > >>
> > >>
> > >> However, based on the further docs at
> > >> https://maven.apache.org/maven-ci-friendly.html, this design would
> > fail:
> > >>
> > >
> > > which is not mentioned in the docs...
> > >
> > >
> > >> <version>${revision}-${sha1}</version>
> > >>
> > >> <properties>
> > >>       <sha1>${buildNumber}</sha1>
> > >> </properties>
> > >>
> > >>
> > >> and call it as -Drevision=1.2.3 -DbuildNumber=99999
> > >>
> > >
> > > The problem is simply that buildNumber is not correctly overwritten
> from
> > > command and not correctly handled duing the model reading /
> interpolation
> > > at the correct time within Maven Core at the moment...
> > >
> > > At the moment this is only implemented for those special three
> > > properties...which already has performance impacts...which is also a
> > reason
> > > not making that possible for all kind of properties...at the moment...
> > >
> > >
> > >>
> > >> Is anyone able to shed some light as to why this would be the case?
> Why
> > >> can a property not be used to compute on of the 3 special vars?
> > >>
> > >> My use case is that I want to supply the build number to all my
> builds,
> > >> but
> > >> only append it to the version if a specific profile is enabled.  In my
> > >> mind, it would be simple - make the sha1 property empty by default,
> and
> > in
> > >> my specific profile, set it to the buildnumber.   But based on my
> > >> understanding, this would fail.
> > >>
> > >> Is my only option in that case to design it as:
> > >>
> > >> <version>${artifactVersion}</version>
> > >> <properties>
> > >>    <artifactVersion>${revision}</artifactVersion>
> > >> </properties>
> > >>
> > >> <profile>
> > >>    <id>buildNumber</id>
> > >>    <properties>
> > >>       <artifactVersion>${revision}-${sha1}</artifactVersion>
> > >>    </properties>
> > >> </profile>
> > >>
> > >>
> > >> What is the reason for this limitation?  Is there any chance that this
> > >> limitation will be removed in the future?
> > >>
> > >
> > > The question is why do you need a profile for this? You can define
> > > defaults in .mvn/maven.config ...and during a CI build you can give
> other
> > > information via command line ?
> > >
> > > I don't see the need for a profile ? Maybe you can elaborate a little
> bit
> > > more what the real problem is ? ...
> > >
> > >
> > > Kind regards
> > > Karl Heinz Marbaise
> > >
> >
>

Re: Special parameters - sha1

Posted by Bernd Eckenfels <ec...@zusammenkunft.net>.

Hello,

If you have a POM with dependencies to other modules which are built on each change, you typically want to make sure you use those updated dependencies when you compile your projects.

With regularly changing version numbers and without using SNAPSHOT dependencies you will need to find a solution for this. You could use version ranges, but then you are not much different then using SNAPSHOT builds. This is one of the main reasons why we are doing manual releases - and managing the dependency versions by hand.

Gruss
Bernd
--
http://bernd.eckenfels.net
________________________________
From: Eric Benzacar <er...@benzacar.ca>
Sent: Thursday, November 16, 2017 5:05:45 AM
To: Maven Users List
Cc: info@soebes.de
Subject: Re: Special <version> parameters - sha1

I'm not sure what you mean when you say:

"How are you planning to deal with the changed version numbers of
dependencies?"

At which stage are you referring to?  Which dependencies with changed
version numbers?

Thanks,

Eric

On Wed, Nov 15, 2017 at 1:11 AM, Bernd Eckenfels <ec...@zusammenkunft.net>
wrote:

> You have to remember that POMs are also the model to describe artifacts,
> that why you should stay clear of profiles (especially if the influence
> artifact coordinates).
>
> Personally I have good experience with actually releasing things, but if
> you want to keep the build identifier, then I would agree, that handling
> this in the build job is probably the best. You can have even two
> Parameterized jobs.
>
> How are you planning to deal with the changed version numbers of
> dependencies?
>
> Gruss
> Bernd
> --
> http://bernd.eckenfels.net
> ________________________________
> From: Eric B <eb...@gmail.com>
> Sent: Wednesday, November 15, 2017 4:30:06 AM
> To: info@soebes.de; Maven Users List
> Subject: Re: Special <version> parameters - sha1
>
> Hi,
>
> Thanks for the additional insight.  I think I understand better now how
> this works.   I'll try to explain my use case, and perhaps someone can
> provide some ideas for best practices.
>
> I started a pom refactoring because I wanted to add the enforcer-plugin for
> a release candidate to ensure there are no SNAPSHOTs in the pom.  For our
> dev purposes, we have defined that anything in a release/ branch (Gitflow)
> is a release candidate.  Anything in the dev/ branch can be a SNAPSHOT.
> Additionally, we use semantic versioning, so our versions read 4.7.0,
> 4.7.1, 5.0.0, 5.1.0, etc...  Consequently, each build coming from a release
> branch needs to have a unique version.  I don't want to update the version
> number for each build, so each build has to have a build number or sha1
> attached to the version.
>
> My build pipeline is very basic for the moment; it's a simple Jenkins
> freestyle job (not a pipeline job yet).  Ideally, I'm trying to keep it as
> simple as possible and always pass the same parameters to the maven build
> process (to make it easier for others to understand).
>
> I'm passing the following parameters to the maven build:
>  -DbranchType=release
>  -DbuildNumber=<jenkins build number>
>
> maven.config:
> -Drevision=5.0.0
>
>
>
> My thought process is I could do the following - for the normal use case
> (ie: dev branch):
> <version>${revision}${changelist}</version>
> <properties>
>   <changelist>-SNAPSHOT</changelist>
> </properties>
>
>
> For a release:
> <profile>
>   <id>relelase</id>
>   <activation>
>     <property>
>        <name>branchType</name>
>        <value>release</value>
>     </property>
>   </activation>
>    <properties>
>       <changelist></changelist>
>       <sha1>${buildNumber}</sha1>
>    </properties>
>     <!-- enable enforcer plugin to prevent SNAPSHOTs etc -->
> </profile>
>
>
> But now I see that won't work.  So I need to pass the buildnumber on the
> command line as a SHA1 parameter.  But if I do that in this design, the
> SNAPSHOT will also include the SHA1 which is not what I want.
>
> So from what I can see, the only option is to modify the parameters on the
> command line.  Which means I have to add some additional logic to my
> Jenkins build.  This would be much easier if I had a Pipeline build but I
> don't at the moment.  I was just looking to put the intelligence in the pom
> so that anyone could easily read & understand it.
>
> Any suggestions or recommendations would be greatly appreciated.  Is there
> anyway to do this in the pom itself?
>
> Thanks,
>
> Eric
>
> On Tue, Nov 14, 2017 at 8:42 AM, Karl Heinz Marbaise <kh...@gmx.de>
> wrote:
>
> > Hi,
> >
> >
> > I will give some more details cause I have created the docs /
> > implementation and you mentioned my blog ;-)..
> >
> >
> > On 14/11/17 03:12, Eric B wrote:
> >
> >> Following a long thread on this list, and a blog by khmarbaise (
> >> http://blog.soebes.de/blog/2017/04/02/maven-pom-files-withou
> >> t-a-version-in-it/),
> >> I'm still a little confused as to exactly what is allowed in the special
> >> version tags for a maven pom.
> >>
> >> I know and realize that the 3 allowable tags are:
> >>   - ${revision}
> >>   - ${sha1}
> >>   - ${changelist}
> >>
> >> However, from the thread and the blog, it seems that these properties
> >> cannot be dependent on any other properties.
> >>
> >
> > Correct.
> >
> >>
> >> For example, this is fine:
> >>         <version>${revision}-${sha1}</version>
> >> where mvn is called with -Drevision=1.2.3 -Dsha1=1a2b3c4e
> >>
> >>
> >> However, based on the further docs at
> >> https://maven.apache.org/maven-ci-friendly.html, this design would
> fail:
> >>
> >
> > which is not mentioned in the docs...
> >
> >
> >> <version>${revision}-${sha1}</version>
> >>
> >> <properties>
> >>       <sha1>${buildNumber}</sha1>
> >> </properties>
> >>
> >>
> >> and call it as -Drevision=1.2.3 -DbuildNumber=99999
> >>
> >
> > The problem is simply that buildNumber is not correctly overwritten from
> > command and not correctly handled duing the model reading / interpolation
> > at the correct time within Maven Core at the moment...
> >
> > At the moment this is only implemented for those special three
> > properties...which already has performance impacts...which is also a
> reason
> > not making that possible for all kind of properties...at the moment...
> >
> >
> >>
> >> Is anyone able to shed some light as to why this would be the case?  Why
> >> can a property not be used to compute on of the 3 special vars?
> >>
> >> My use case is that I want to supply the build number to all my builds,
> >> but
> >> only append it to the version if a specific profile is enabled.  In my
> >> mind, it would be simple - make the sha1 property empty by default, and
> in
> >> my specific profile, set it to the buildnumber.   But based on my
> >> understanding, this would fail.
> >>
> >> Is my only option in that case to design it as:
> >>
> >> <version>${artifactVersion}</version>
> >> <properties>
> >>    <artifactVersion>${revision}</artifactVersion>
> >> </properties>
> >>
> >> <profile>
> >>    <id>buildNumber</id>
> >>    <properties>
> >>       <artifactVersion>${revision}-${sha1}</artifactVersion>
> >>    </properties>
> >> </profile>
> >>
> >>
> >> What is the reason for this limitation?  Is there any chance that this
> >> limitation will be removed in the future?
> >>
> >
> > The question is why do you need a profile for this? You can define
> > defaults in .mvn/maven.config ...and during a CI build you can give other
> > information via command line ?
> >
> > I don't see the need for a profile ? Maybe you can elaborate a little bit
> > more what the real problem is ? ...
> >
> >
> > Kind regards
> > Karl Heinz Marbaise
> >
>

Re: Special parameters - sha1

Posted by Eric Benzacar <er...@benzacar.ca>.

I'm not sure what you mean when you say:

"How are you planning to deal with the changed version numbers of
dependencies?"

At which stage are you referring to?  Which dependencies with changed
version numbers?

Thanks,

Eric

On Wed, Nov 15, 2017 at 1:11 AM, Bernd Eckenfels <ec...@zusammenkunft.net>
wrote:

> You have to remember that POMs are also the model to describe artifacts,
> that why you should stay clear of profiles (especially if the influence
> artifact coordinates).
>
> Personally I have good experience with actually releasing things, but if
> you want to keep the build identifier, then I would agree, that handling
> this in the build job is probably the best. You can have even two
> Parameterized jobs.
>
> How are you planning to deal with the changed version numbers of
> dependencies?
>
> Gruss
> Bernd
> --
> http://bernd.eckenfels.net
> ________________________________
> From: Eric B <eb...@gmail.com>
> Sent: Wednesday, November 15, 2017 4:30:06 AM
> To: info@soebes.de; Maven Users List
> Subject: Re: Special <version> parameters - sha1
>
> Hi,
>
> Thanks for the additional insight.  I think I understand better now how
> this works.   I'll try to explain my use case, and perhaps someone can
> provide some ideas for best practices.
>
> I started a pom refactoring because I wanted to add the enforcer-plugin for
> a release candidate to ensure there are no SNAPSHOTs in the pom.  For our
> dev purposes, we have defined that anything in a release/ branch (Gitflow)
> is a release candidate.  Anything in the dev/ branch can be a SNAPSHOT.
> Additionally, we use semantic versioning, so our versions read 4.7.0,
> 4.7.1, 5.0.0, 5.1.0, etc...  Consequently, each build coming from a release
> branch needs to have a unique version.  I don't want to update the version
> number for each build, so each build has to have a build number or sha1
> attached to the version.
>
> My build pipeline is very basic for the moment; it's a simple Jenkins
> freestyle job (not a pipeline job yet).  Ideally, I'm trying to keep it as
> simple as possible and always pass the same parameters to the maven build
> process (to make it easier for others to understand).
>
> I'm passing the following parameters to the maven build:
>  -DbranchType=release
>  -DbuildNumber=<jenkins build number>
>
> maven.config:
> -Drevision=5.0.0
>
>
>
> My thought process is I could do the following - for the normal use case
> (ie: dev branch):
> <version>${revision}${changelist}</version>
> <properties>
>   <changelist>-SNAPSHOT</changelist>
> </properties>
>
>
> For a release:
> <profile>
>   <id>relelase</id>
>   <activation>
>     <property>
>        <name>branchType</name>
>        <value>release</value>
>     </property>
>   </activation>
>    <properties>
>       <changelist></changelist>
>       <sha1>${buildNumber}</sha1>
>    </properties>
>     <!-- enable enforcer plugin to prevent SNAPSHOTs etc -->
> </profile>
>
>
> But now I see that won't work.  So I need to pass the buildnumber on the
> command line as a SHA1 parameter.  But if I do that in this design, the
> SNAPSHOT will also include the SHA1 which is not what I want.
>
> So from what I can see, the only option is to modify the parameters on the
> command line.  Which means I have to add some additional logic to my
> Jenkins build.  This would be much easier if I had a Pipeline build but I
> don't at the moment.  I was just looking to put the intelligence in the pom
> so that anyone could easily read & understand it.
>
> Any suggestions or recommendations would be greatly appreciated.  Is there
> anyway to do this in the pom itself?
>
> Thanks,
>
> Eric
>
> On Tue, Nov 14, 2017 at 8:42 AM, Karl Heinz Marbaise <kh...@gmx.de>
> wrote:
>
> > Hi,
> >
> >
> > I will give some more details cause I have created the docs /
> > implementation and you mentioned my blog ;-)..
> >
> >
> > On 14/11/17 03:12, Eric B wrote:
> >
> >> Following a long thread on this list, and a blog by khmarbaise (
> >> http://blog.soebes.de/blog/2017/04/02/maven-pom-files-withou
> >> t-a-version-in-it/),
> >> I'm still a little confused as to exactly what is allowed in the special
> >> version tags for a maven pom.
> >>
> >> I know and realize that the 3 allowable tags are:
> >>   - ${revision}
> >>   - ${sha1}
> >>   - ${changelist}
> >>
> >> However, from the thread and the blog, it seems that these properties
> >> cannot be dependent on any other properties.
> >>
> >
> > Correct.
> >
> >>
> >> For example, this is fine:
> >>         <version>${revision}-${sha1}</version>
> >> where mvn is called with -Drevision=1.2.3 -Dsha1=1a2b3c4e
> >>
> >>
> >> However, based on the further docs at
> >> https://maven.apache.org/maven-ci-friendly.html, this design would
> fail:
> >>
> >
> > which is not mentioned in the docs...
> >
> >
> >> <version>${revision}-${sha1}</version>
> >>
> >> <properties>
> >>       <sha1>${buildNumber}</sha1>
> >> </properties>
> >>
> >>
> >> and call it as -Drevision=1.2.3 -DbuildNumber=99999
> >>
> >
> > The problem is simply that buildNumber is not correctly overwritten from
> > command and not correctly handled duing the model reading / interpolation
> > at the correct time within Maven Core at the moment...
> >
> > At the moment this is only implemented for those special three
> > properties...which already has performance impacts...which is also a
> reason
> > not making that possible for all kind of properties...at the moment...
> >
> >
> >>
> >> Is anyone able to shed some light as to why this would be the case?  Why
> >> can a property not be used to compute on of the 3 special vars?
> >>
> >> My use case is that I want to supply the build number to all my builds,
> >> but
> >> only append it to the version if a specific profile is enabled.  In my
> >> mind, it would be simple - make the sha1 property empty by default, and
> in
> >> my specific profile, set it to the buildnumber.   But based on my
> >> understanding, this would fail.
> >>
> >> Is my only option in that case to design it as:
> >>
> >> <version>${artifactVersion}</version>
> >> <properties>
> >>    <artifactVersion>${revision}</artifactVersion>
> >> </properties>
> >>
> >> <profile>
> >>    <id>buildNumber</id>
> >>    <properties>
> >>       <artifactVersion>${revision}-${sha1}</artifactVersion>
> >>    </properties>
> >> </profile>
> >>
> >>
> >> What is the reason for this limitation?  Is there any chance that this
> >> limitation will be removed in the future?
> >>
> >
> > The question is why do you need a profile for this? You can define
> > defaults in .mvn/maven.config ...and during a CI build you can give other
> > information via command line ?
> >
> > I don't see the need for a profile ? Maybe you can elaborate a little bit
> > more what the real problem is ? ...
> >
> >
> > Kind regards
> > Karl Heinz Marbaise
> >
>

Re: Special parameters - sha1

Posted by Bernd Eckenfels <ec...@zusammenkunft.net>.

You have to remember that POMs are also the model to describe artifacts, that why you should stay clear of profiles (especially if the influence artifact coordinates).

Personally I have good experience with actually releasing things, but if you want to keep the build identifier, then I would agree, that handling this in the build job is probably the best. You can have even two Parameterized jobs.

How are you planning to deal with the changed version numbers of dependencies?

Gruss
Bernd
--
http://bernd.eckenfels.net
________________________________
From: Eric B <eb...@gmail.com>
Sent: Wednesday, November 15, 2017 4:30:06 AM
To: info@soebes.de; Maven Users List
Subject: Re: Special <version> parameters - sha1

Hi,

Thanks for the additional insight.  I think I understand better now how
this works.   I'll try to explain my use case, and perhaps someone can
provide some ideas for best practices.

I started a pom refactoring because I wanted to add the enforcer-plugin for
a release candidate to ensure there are no SNAPSHOTs in the pom.  For our
dev purposes, we have defined that anything in a release/ branch (Gitflow)
is a release candidate.  Anything in the dev/ branch can be a SNAPSHOT.
Additionally, we use semantic versioning, so our versions read 4.7.0,
4.7.1, 5.0.0, 5.1.0, etc...  Consequently, each build coming from a release
branch needs to have a unique version.  I don't want to update the version
number for each build, so each build has to have a build number or sha1
attached to the version.

My build pipeline is very basic for the moment; it's a simple Jenkins
freestyle job (not a pipeline job yet).  Ideally, I'm trying to keep it as
simple as possible and always pass the same parameters to the maven build
process (to make it easier for others to understand).

I'm passing the following parameters to the maven build:
 -DbranchType=release
 -DbuildNumber=<jenkins build number>

maven.config:
-Drevision=5.0.0

My thought process is I could do the following - for the normal use case
(ie: dev branch):
<version>${revision}${changelist}</version>
<properties>
  <changelist>-SNAPSHOT</changelist>
</properties>

For a release:
<profile>
  <id>relelase</id>
  <activation>
    <property>
       <name>branchType</name>
       <value>release</value>
    </property>
  </activation>
   <properties>
      <changelist></changelist>
      <sha1>${buildNumber}</sha1>
   </properties>
    <!-- enable enforcer plugin to prevent SNAPSHOTs etc -->
</profile>

But now I see that won't work.  So I need to pass the buildnumber on the
command line as a SHA1 parameter.  But if I do that in this design, the
SNAPSHOT will also include the SHA1 which is not what I want.

So from what I can see, the only option is to modify the parameters on the
command line.  Which means I have to add some additional logic to my
Jenkins build.  This would be much easier if I had a Pipeline build but I
don't at the moment.  I was just looking to put the intelligence in the pom
so that anyone could easily read & understand it.

Any suggestions or recommendations would be greatly appreciated.  Is there
anyway to do this in the pom itself?

Thanks,

Eric

On Tue, Nov 14, 2017 at 8:42 AM, Karl Heinz Marbaise <kh...@gmx.de>
wrote:

> Hi,
>
>
> I will give some more details cause I have created the docs /
> implementation and you mentioned my blog ;-)..
>
>
> On 14/11/17 03:12, Eric B wrote:
>
>> Following a long thread on this list, and a blog by khmarbaise (
>> http://blog.soebes.de/blog/2017/04/02/maven-pom-files-withou
>> t-a-version-in-it/),
>> I'm still a little confused as to exactly what is allowed in the special
>> version tags for a maven pom.
>>
>> I know and realize that the 3 allowable tags are:
>>   - ${revision}
>>   - ${sha1}
>>   - ${changelist}
>>
>> However, from the thread and the blog, it seems that these properties
>> cannot be dependent on any other properties.
>>
>
> Correct.
>
>>
>> For example, this is fine:
>>         <version>${revision}-${sha1}</version>
>> where mvn is called with -Drevision=1.2.3 -Dsha1=1a2b3c4e
>>
>>
>> However, based on the further docs at
>> https://maven.apache.org/maven-ci-friendly.html, this design would fail:
>>
>
> which is not mentioned in the docs...
>
>
>> <version>${revision}-${sha1}</version>
>>
>> <properties>
>>       <sha1>${buildNumber}</sha1>
>> </properties>
>>
>>
>> and call it as -Drevision=1.2.3 -DbuildNumber=99999
>>
>
> The problem is simply that buildNumber is not correctly overwritten from
> command and not correctly handled duing the model reading / interpolation
> at the correct time within Maven Core at the moment...
>
> At the moment this is only implemented for those special three
> properties...which already has performance impacts...which is also a reason
> not making that possible for all kind of properties...at the moment...
>
>
>>
>> Is anyone able to shed some light as to why this would be the case?  Why
>> can a property not be used to compute on of the 3 special vars?
>>
>> My use case is that I want to supply the build number to all my builds,
>> but
>> only append it to the version if a specific profile is enabled.  In my
>> mind, it would be simple - make the sha1 property empty by default, and in
>> my specific profile, set it to the buildnumber.   But based on my
>> understanding, this would fail.
>>
>> Is my only option in that case to design it as:
>>
>> <version>${artifactVersion}</version>
>> <properties>
>>    <artifactVersion>${revision}</artifactVersion>
>> </properties>
>>
>> <profile>
>>    <id>buildNumber</id>
>>    <properties>
>>       <artifactVersion>${revision}-${sha1}</artifactVersion>
>>    </properties>
>> </profile>
>>
>>
>> What is the reason for this limitation?  Is there any chance that this
>> limitation will be removed in the future?
>>
>
> The question is why do you need a profile for this? You can define
> defaults in .mvn/maven.config ...and during a CI build you can give other
> information via command line ?
>
> I don't see the need for a profile ? Maybe you can elaborate a little bit
> more what the real problem is ? ...
>
>
> Kind regards
> Karl Heinz Marbaise
>

Re: Special parameters - sha1

Posted by Eric B <eb...@gmail.com>.

Hi,

Thanks for the additional insight.  I think I understand better now how
this works.   I'll try to explain my use case, and perhaps someone can
provide some ideas for best practices.

I started a pom refactoring because I wanted to add the enforcer-plugin for
a release candidate to ensure there are no SNAPSHOTs in the pom.  For our
dev purposes, we have defined that anything in a release/ branch (Gitflow)
is a release candidate.  Anything in the dev/ branch can be a SNAPSHOT.
Additionally, we use semantic versioning, so our versions read 4.7.0,
4.7.1, 5.0.0, 5.1.0, etc...  Consequently, each build coming from a release
branch needs to have a unique version.  I don't want to update the version
number for each build, so each build has to have a build number or sha1
attached to the version.

My build pipeline is very basic for the moment; it's a simple Jenkins
freestyle job (not a pipeline job yet).  Ideally, I'm trying to keep it as
simple as possible and always pass the same parameters to the maven build
process (to make it easier for others to understand).

I'm passing the following parameters to the maven build:
 -DbranchType=release
 -DbuildNumber=<jenkins build number>

maven.config:
-Drevision=5.0.0

My thought process is I could do the following - for the normal use case
(ie: dev branch):
<version>${revision}${changelist}</version>
<properties>
  <changelist>-SNAPSHOT</changelist>
</properties>

For a release:
<profile>
  <id>relelase</id>
  <activation>
    <property>
       <name>branchType</name>
       <value>release</value>
    </property>
  </activation>
   <properties>
      <changelist></changelist>
      <sha1>${buildNumber}</sha1>
   </properties>
    <!-- enable enforcer plugin to prevent SNAPSHOTs etc -->
</profile>

But now I see that won't work.  So I need to pass the buildnumber on the
command line as a SHA1 parameter.  But if I do that in this design, the
SNAPSHOT will also include the SHA1 which is not what I want.

So from what I can see, the only option is to modify the parameters on the
command line.  Which means I have to add some additional logic to my
Jenkins build.  This would be much easier if I had a Pipeline build but I
don't at the moment.  I was just looking to put the intelligence in the pom
so that anyone could easily read & understand it.

Any suggestions or recommendations would be greatly appreciated.  Is there
anyway to do this in the pom itself?

Thanks,

Eric

On Tue, Nov 14, 2017 at 8:42 AM, Karl Heinz Marbaise <kh...@gmx.de>
wrote:

> Hi,
>
>
> I will give some more details cause I have created the docs /
> implementation and you mentioned my blog ;-)..
>
>
> On 14/11/17 03:12, Eric B wrote:
>
>> Following a long thread on this list, and a blog by khmarbaise (
>> http://blog.soebes.de/blog/2017/04/02/maven-pom-files-withou
>> t-a-version-in-it/),
>> I'm still a little confused as to exactly what is allowed in the special
>> version tags for a maven pom.
>>
>> I know and realize that the 3 allowable tags are:
>>   - ${revision}
>>   - ${sha1}
>>   - ${changelist}
>>
>> However, from the thread and the blog, it seems that these properties
>> cannot be dependent on any other properties.
>>
>
> Correct.
>
>>
>> For example, this is fine:
>>         <version>${revision}-${sha1}</version>
>> where mvn is called with -Drevision=1.2.3 -Dsha1=1a2b3c4e
>>
>>
>> However, based on the further docs at
>> https://maven.apache.org/maven-ci-friendly.html, this design would fail:
>>
>
> which is not mentioned in the docs...
>
>
>> <version>${revision}-${sha1}</version>
>>
>> <properties>
>>       <sha1>${buildNumber}</sha1>
>> </properties>
>>
>>
>> and call it as -Drevision=1.2.3 -DbuildNumber=99999
>>
>
> The problem is simply that buildNumber is not correctly overwritten from
> command and not correctly handled duing the model reading / interpolation
> at the correct time within Maven Core at the moment...
>
> At the moment this is only implemented for those special three
> properties...which already has performance impacts...which is also a reason
> not making that possible for all kind of properties...at the moment...
>
>
>>
>> Is anyone able to shed some light as to why this would be the case?  Why
>> can a property not be used to compute on of the 3 special vars?
>>
>> My use case is that I want to supply the build number to all my builds,
>> but
>> only append it to the version if a specific profile is enabled.  In my
>> mind, it would be simple - make the sha1 property empty by default, and in
>> my specific profile, set it to the buildnumber.   But based on my
>> understanding, this would fail.
>>
>> Is my only option in that case to design it as:
>>
>> <version>${artifactVersion}</version>
>> <properties>
>>    <artifactVersion>${revision}</artifactVersion>
>> </properties>
>>
>> <profile>
>>    <id>buildNumber</id>
>>    <properties>
>>       <artifactVersion>${revision}-${sha1}</artifactVersion>
>>    </properties>
>> </profile>
>>
>>
>> What is the reason for this limitation?  Is there any chance that this
>> limitation will be removed in the future?
>>
>
> The question is why do you need a profile for this? You can define
> defaults in .mvn/maven.config ...and during a CI build you can give other
> information via command line ?
>
> I don't see the need for a profile ? Maybe you can elaborate a little bit
> more what the real problem is ? ...
>
>
> Kind regards
> Karl Heinz Marbaise
>

Re: Special parameters - sha1

Posted by Karl Heinz Marbaise <kh...@gmx.de>.

Hi,


I will give some more details cause I have created the docs / 
implementation and you mentioned my blog ;-)..


On 14/11/17 03:12, Eric B wrote:
> Following a long thread on this list, and a blog by khmarbaise (
> http://blog.soebes.de/blog/2017/04/02/maven-pom-files-without-a-version-in-it/),
> I'm still a little confused as to exactly what is allowed in the special
> version tags for a maven pom.
> 
> I know and realize that the 3 allowable tags are:
>   - ${revision}
>   - ${sha1}
>   - ${changelist}
> 
> However, from the thread and the blog, it seems that these properties
> cannot be dependent on any other properties.

Correct.
> 
> For example, this is fine:
>         <version>${revision}-${sha1}</version>
> where mvn is called with -Drevision=1.2.3 -Dsha1=1a2b3c4e
> 
> 
> However, based on the further docs at
> https://maven.apache.org/maven-ci-friendly.html, this design would fail:

which is not mentioned in the docs...

> 
> <version>${revision}-${sha1}</version>
> 
> <properties>
>       <sha1>${buildNumber}</sha1>
> </properties>
> 
> 
> and call it as -Drevision=1.2.3 -DbuildNumber=99999

The problem is simply that buildNumber is not correctly overwritten from 
command and not correctly handled duing the model reading / 
interpolation at the correct time within Maven Core at the moment...

At the moment this is only implemented for those special three 
properties...which already has performance impacts...which is also a 
reason not making that possible for all kind of properties...at the 
moment...

> 
> 
> Is anyone able to shed some light as to why this would be the case?  Why
> can a property not be used to compute on of the 3 special vars?
> 
> My use case is that I want to supply the build number to all my builds, but
> only append it to the version if a specific profile is enabled.  In my
> mind, it would be simple - make the sha1 property empty by default, and in
> my specific profile, set it to the buildnumber.   But based on my
> understanding, this would fail.
> 
> Is my only option in that case to design it as:
> 
> <version>${artifactVersion}</version>
> <properties>
>    <artifactVersion>${revision}</artifactVersion>
> </properties>
> 
> <profile>
>    <id>buildNumber</id>
>    <properties>
>       <artifactVersion>${revision}-${sha1}</artifactVersion>
>    </properties>
> </profile>
> 
> 
> What is the reason for this limitation?  Is there any chance that this
> limitation will be removed in the future?

The question is why do you need a profile for this? You can define 
defaults in .mvn/maven.config ...and during a CI build you can give 
other information via command line ?

I don't see the need for a profile ? Maybe you can elaborate a little 
bit more what the real problem is ? ...


Kind regards
Karl Heinz Marbaise

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Special parameters - sha1

Posted by Bernd Eckenfels <ec...@zusammenkunft.net>.

Hello,

From maven points of view it needs to construct a complete model before operating on it. That it is why it cannot dynamically calculate the values of nested properties. So the 3 values are picked to be allowed to be specified externally, with the understanding that they don’t need to be calculated by maven.

However nothing stops you from dynamically constructing the values from outside (with Shell variables or pgrammatically with expressionism your CI Seever)

  mvn -Drevision="-$DATE-$BUildNumber" -Dchangelist="-nightly" test

    <Version>1.2.3${revision}${changelist}</Version>

Gruss
Bernd
--
http://bernd.eckenfels.net
________________________________
From: Eric B <eb...@gmail.com>
Sent: Tuesday, November 14, 2017 4:16:08 AM
To: Maven Users List
Subject: Re: Special <version> parameters - sha1

Bernd,

Is my understanding correct though?  These three properties cannot contain
any property values?  They can only contain constants?  Can they contain
other command line values, or not even?

Can you elaborate why it was deemed necessary to restrict the expansion to
a fixed set?  What was the reasoning behind that?

Thanks,

Eric


On Mon, Nov 13, 2017 at 9:21 PM, Bernd Eckenfels <ec...@zusammenkunft.net>
wrote:

> You can use the 3 Properties in any way you want it, their name suggest a
> certain content, and it was deemed necessary to restrict the expansion to a
> fixed set. so the 3 have been picked to give some guidance on what are sane
> modifiers.
>
> You will most likely use revision for the Version and changelist or sha
> for the incremental builds, but you can also cram everything into revision,
> Maven does not really care how you use them (as long as you use nothing
> else)
>
> Gruss
> Bernd
> --
> http://bernd.eckenfels.net
> ________________________________
> From: Eric B <eb...@gmail.com>
> Sent: Tuesday, November 14, 2017 3:12:21 AM
> To: Maven Users List
> Subject: Special <version> parameters - sha1
>
> Following a long thread on this list, and a blog by khmarbaise (
> http://blog.soebes.de/blog/2017/04/02/maven-pom-files-
> without-a-version-in-it/),
> I'm still a little confused as to exactly what is allowed in the special
> version tags for a maven pom.
>
> I know and realize that the 3 allowable tags are:
>  - ${revision}
>  - ${sha1}
>  - ${changelist}
>
> However, from the thread and the blog, it seems that these properties
> cannot be dependent on any other properties.
>
> For example, this is fine:
>        <version>${revision}-${sha1}</version>
> where mvn is called with -Drevision=1.2.3 -Dsha1=1a2b3c4e
>
>
> However, based on the further docs at
> https://maven.apache.org/maven-ci-friendly.html, this design would fail:
>
> <version>${revision}-${sha1}</version>
>
> <properties>
>      <sha1>${buildNumber}</sha1>
> </properties>
>
>
> and call it as -Drevision=1.2.3 -DbuildNumber=99999
>
>
> Is anyone able to shed some light as to why this would be the case?  Why
> can a property not be used to compute on of the 3 special vars?
>
> My use case is that I want to supply the build number to all my builds, but
> only append it to the version if a specific profile is enabled.  In my
> mind, it would be simple - make the sha1 property empty by default, and in
> my specific profile, set it to the buildnumber.   But based on my
> understanding, this would fail.
>
> Is my only option in that case to design it as:
>
> <version>${artifactVersion}</version>
> <properties>
>   <artifactVersion>${revision}</artifactVersion>
> </properties>
>
> <profile>
>   <id>buildNumber</id>
>   <properties>
>      <artifactVersion>${revision}-${sha1}</artifactVersion>
>   </properties>
> </profile>
>
>
> What is the reason for this limitation?  Is there any chance that this
> limitation will be removed in the future?
>
> Thanks,
>
> Eric
>

Re: Special parameters - sha1

Posted by Eric B <eb...@gmail.com>.

Bernd,

Is my understanding correct though?  These three properties cannot contain
any property values?  They can only contain constants?  Can they contain
other command line values, or not even?

Can you elaborate why it was deemed necessary to restrict the expansion to
a fixed set?  What was the reasoning behind that?

Thanks,

Eric


On Mon, Nov 13, 2017 at 9:21 PM, Bernd Eckenfels <ec...@zusammenkunft.net>
wrote:

> You can use the 3 Properties in any way you want it, their name suggest a
> certain content, and it was deemed necessary to restrict the expansion to a
> fixed set. so the 3 have been picked to give some guidance on what are sane
> modifiers.
>
> You will most likely use revision for the Version and changelist or sha
> for the incremental builds, but you can also cram everything into revision,
> Maven does not really care how you use them (as long as you use nothing
> else)
>
> Gruss
> Bernd
> --
> http://bernd.eckenfels.net
> ________________________________
> From: Eric B <eb...@gmail.com>
> Sent: Tuesday, November 14, 2017 3:12:21 AM
> To: Maven Users List
> Subject: Special <version> parameters - sha1
>
> Following a long thread on this list, and a blog by khmarbaise (
> http://blog.soebes.de/blog/2017/04/02/maven-pom-files-
> without-a-version-in-it/),
> I'm still a little confused as to exactly what is allowed in the special
> version tags for a maven pom.
>
> I know and realize that the 3 allowable tags are:
>  - ${revision}
>  - ${sha1}
>  - ${changelist}
>
> However, from the thread and the blog, it seems that these properties
> cannot be dependent on any other properties.
>
> For example, this is fine:
>        <version>${revision}-${sha1}</version>
> where mvn is called with -Drevision=1.2.3 -Dsha1=1a2b3c4e
>
>
> However, based on the further docs at
> https://maven.apache.org/maven-ci-friendly.html, this design would fail:
>
> <version>${revision}-${sha1}</version>
>
> <properties>
>      <sha1>${buildNumber}</sha1>
> </properties>
>
>
> and call it as -Drevision=1.2.3 -DbuildNumber=99999
>
>
> Is anyone able to shed some light as to why this would be the case?  Why
> can a property not be used to compute on of the 3 special vars?
>
> My use case is that I want to supply the build number to all my builds, but
> only append it to the version if a specific profile is enabled.  In my
> mind, it would be simple - make the sha1 property empty by default, and in
> my specific profile, set it to the buildnumber.   But based on my
> understanding, this would fail.
>
> Is my only option in that case to design it as:
>
> <version>${artifactVersion}</version>
> <properties>
>   <artifactVersion>${revision}</artifactVersion>
> </properties>
>
> <profile>
>   <id>buildNumber</id>
>   <properties>
>      <artifactVersion>${revision}-${sha1}</artifactVersion>
>   </properties>
> </profile>
>
>
> What is the reason for this limitation?  Is there any chance that this
> limitation will be removed in the future?
>
> Thanks,
>
> Eric
>

Re: Special parameters - sha1

Posted by Bernd Eckenfels <ec...@zusammenkunft.net>.

You can use the 3 Properties in any way you want it, their name suggest a certain content, and it was deemed necessary to restrict the expansion to a fixed set. so the 3 have been picked to give some guidance on what are sane modifiers.

You will most likely use revision for the Version and changelist or sha for the incremental builds, but you can also cram everything into revision, Maven does not really care how you use them (as long as you use nothing else)

Gruss
Bernd
--
http://bernd.eckenfels.net
________________________________
From: Eric B <eb...@gmail.com>
Sent: Tuesday, November 14, 2017 3:12:21 AM
To: Maven Users List
Subject: Special <version> parameters - sha1

Following a long thread on this list, and a blog by khmarbaise (
http://blog.soebes.de/blog/2017/04/02/maven-pom-files-without-a-version-in-it/),
I'm still a little confused as to exactly what is allowed in the special
version tags for a maven pom.

I know and realize that the 3 allowable tags are:
 - ${revision}
 - ${sha1}
 - ${changelist}

However, from the thread and the blog, it seems that these properties
cannot be dependent on any other properties.

For example, this is fine:
       <version>${revision}-${sha1}</version>
where mvn is called with -Drevision=1.2.3 -Dsha1=1a2b3c4e


However, based on the further docs at
https://maven.apache.org/maven-ci-friendly.html, this design would fail:

<version>${revision}-${sha1}</version>

<properties>
     <sha1>${buildNumber}</sha1>
</properties>


and call it as -Drevision=1.2.3 -DbuildNumber=99999


Is anyone able to shed some light as to why this would be the case?  Why
can a property not be used to compute on of the 3 special vars?

My use case is that I want to supply the build number to all my builds, but
only append it to the version if a specific profile is enabled.  In my
mind, it would be simple - make the sha1 property empty by default, and in
my specific profile, set it to the buildnumber.   But based on my
understanding, this would fail.

Is my only option in that case to design it as:

<version>${artifactVersion}</version>
<properties>
  <artifactVersion>${revision}</artifactVersion>
</properties>

<profile>
  <id>buildNumber</id>
  <properties>
     <artifactVersion>${revision}-${sha1}</artifactVersion>
  </properties>
</profile>


What is the reason for this limitation?  Is there any chance that this
limitation will be removed in the future?

Thanks,

Eric