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 < [email protected]> wrote: > On Fri 17 Nov 2017 at 21:07, Stephen Connolly < > [email protected]> wrote: > > > > > On Fri 17 Nov 2017 at 13:57, Eric B <[email protected]> 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" <[email protected]> > >> 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 <[email protected]> > >> > Sent: Thursday, November 16, 2017 5:05:45 AM > >> > To: Maven Users List > >> > Cc: [email protected] > >> > 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 < > >> [email protected]> > >> > 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 <[email protected]> > >> > > Sent: Wednesday, November 15, 2017 4:30:06 AM > >> > > To: [email protected]; 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 < > >> [email protected]> > >> > > 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 >
