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
