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 <ebenza...@gmail.com> Sent: Wednesday, November 15, 2017 4:30:06 AM To: i...@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 <khmarba...@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 >
