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" <e...@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 <e...@benzacar.ca> > Sent: Thursday, November 16, 2017 5:05:45 AM > To: Maven Users List > Cc: i...@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 <e...@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 <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 > > > > > >
