On Fri 17 Nov 2017 at 13:57, Eric B <ebenza...@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" <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 > > > > > > > > > > -- Sent from my phone
