Right... That will give me a build number, but I still need to figure a way to provide the version number to the build. That one had me stumped.
Thanks Eric On May 9, 2017 10:46 PM, "Bernd Eckenfels" <e...@zusammenkunft.net> wrote: > You can use the Jenkins environment variable for the build number of a job > as a read-only parameter. And I think ${env.BUILD_NUMBER} should also work > on the command line. > > Gruss > Bernd > -- > http://bernd.eckenfels.net > ________________________________ > From: Eric Benzacar <e...@benzacar.ca> > Sent: Wednesday, May 10, 2017 3:32:43 AM > To: Maven Users List; i...@soebes.de > Subject: Re: [EXTERNAL] RE: Continuous Delivery with Maven now possible? > > Thanks for the detailed explanation. > > A couple of questions come to mind: > > 1) can the <version> element only contain a variables, or can it be a > combination of fixed + variable? > for instance: > <version>1.2-${changelist}</version> > > I see in your examples that it only is a combination of variables with no > additional text. > > > 2) How do you handle your CD build definitions, given the need to pass the > revision number at build time? Do you end up creating new build > definitions for each version, edit the existing build definition for a new > version, or is there a way to create a generic build definition that can > handle this case? > > I'm using Jenkins and my biggest annoyance is the need to update/modify my > Jenkins job definitions. I could potentially create parameterized build > defn, where the user enters the rev #, but that is just going to be error > prone. I'm trying to remove as much of the human element from this as > possible. > > Is there a way to design the job definition so that I don't have to specify > this information? I realize that I can use the mvn.config file to specify > the revision value but what is the advantage of using that and changing > that file for each version rather than just changing the pom file itself? > Isn't it just shifting the problem from one place to another? > > Thanks, > > Eric > > > On Mon, May 8, 2017 at 1:27 PM, Karl Heinz Marbaise <khmarba...@gmx.de> > wrote: > > > Hi to all, > > > > I think it is needed to explain that in more detail (means also to > improve > > the ci documentation). > > > > > > Let me start with the following: > > > > You can only use those three names "revision", "changelist" and "sha1" in > > a version tag of the pom file cause they are handled special (the > > foundation of its handling is given by the explanation of Bernd Eckenfeld > > Thanks to Bernd). > > > > This means in consequence the given part will not work as expected (at > the > > moment): > > > > <groupId>com.soebes.examples.j2ee</groupId> > <artifactId>parent</artifactId > > > > > <version>${revision}</version> > > <packaging>pom</packaging> > > <properties> > > <revision>1.2.1-${buildNumber}</revision> > > <buildNumber>SNAPSHOT</buildNumber> > > </properties> > > > > > > If you like to make combinations you can do it like this for example: > > (https://github.com/khmarbaise/javaee/tree/maven350-properties): > > > > <groupId>com.soebes.examples.j2ee</groupId> > > <artifactId>parent</artifactId> > > <version>${revision}${sha1}${changelist}</version> > > <packaging>pom</packaging> > > > > <properties> > > <maven.compiler.target>1.6</maven.compiler.target> > > <maven.compiler.source>1.6</maven.compiler.source> > > <revision>1.3.1</revision> > > <changelist>-SNAPSHOT</changelist> > > <sha1/> > > </properties> > > > > or to pickup the previous example which should look like this: > > > > <groupId>com.soebes.examples.j2ee</groupId> > <artifactId>parent</artifactId > > > > > <version>${revision}${changelist}</version> > > <packaging>pom</packaging> > > <properties> > > <revision>1.2.1</revision> > > <changelist>-SNAPSHOT</changelist> > > </properties> > > > > So now your build will work as expected. > > > > If you like to switch to release you simply do that by using the > following: > > > > mvn -Dchangelist= clean package (This will define changelist as empty). > > > > Or if you like to give a buildNumber from commandline: > > > > mvn -Dchangelist=-23-SNAPSHOT clean package > > > > So to make it more convenient you can define the versions like this: > > > > <groupId>com.soebes.examples.j2ee</groupId> > > <artifactId>parent</artifactId> > > <version>${revision}${sha1}${changelist}</version> > > <packaging>pom</packaging> > > > > <properties> > > <maven.compiler.target>1.6</maven.compiler.target> > > <maven.compiler.source>1.6</maven.compiler.source> > > <revision>1.3.1</revision> > > <changelist>-SNAPSHOT</changelist> > > <sha1/> > > </properties> > > > > So now I can build via (be carefull with the separator between version > and > > buildnumber "-"): > > > > mvn -Dsha1=-123 clean package > > > > By the above you can now define many combinatations on the command line: > > > > mvn -Dchangelist= clean package > > > > This means the command line overwrites the values of the properties which > > are defined in the pom file (properties section). > > > > You can of course remove the properties (properties section) from the pom > > file at all and only define the information on command line (works in > > Eclipse). But you can also define those things in ".mvn/maven.config" via > > the appropriate "-D...". > > > > > > So now lets come to the point about flatten-maven-plugin: > > > > Assume you are using above proerties in kind of flavour...now you are > > using my example( https://github.com/khmarbaise/ > > javaee/tree/maven350-properties) without the flatten-maven-plugin in the > > build: > > > > mvn install > > > > The result of that would be having a folder in your local cache like etc. > > where you find a jar file and of course a pom file: (I just picked up two > > files as example): > > > > $HOME/.m2/repository/com/soebes/examples/j2ee/parent/1.3.1- > > SNAPSHOT/parent-1.3.1-SNAPSHOT.pom > > $HOME//.m2/repository/com/soebes/examples/j2ee/domain/1.3.1- > > SNAPSHOT/domain-1.3.1-SNAPSHOT.jar > > > > Looks Ok so far? But let us take a look into the pom file: > > > > The pom file will look like this: > > > > > > <groupId>com.soebes.examples.j2ee</groupId> > > <artifactId>parent</artifactId> > > <version>${revision}${sha1}${changelist}</version> > > <packaging>pom</packaging> > > > > <properties> > > <maven.compiler.target>1.6</maven.compiler.target> > > <maven.compiler.source>1.6</maven.compiler.source> > > <revision>1.3.1</revision> > > <changelist>-SNAPSHOT</changelist> > > <sha1/> > > </properties> > > > > This looks ok so far (on the first glance) > > > > But now I have given mvn -Drevision=2.0.0 install > > > > There will produced also files like this: > > > > $HOME/.m2/repository/com/soebes/examples/j2ee/parent/2.0.0- > > SNAPSHOT/parent-2.0.0-SNAPSHOT.pom > > > > The pom file will look like exactly the same: > > > > > > <groupId>com.soebes.examples.j2ee</groupId> > > <artifactId>parent</artifactId> > > <version>${revision}${sha1}${changelist}</version> > > <packaging>pom</packaging> > > > > <properties> > > <maven.compiler.target>1.6</maven.compiler.target> > > <maven.compiler.source>1.6</maven.compiler.source> > > <revision>1.3.1</revision> > > <changelist>-SNAPSHOT</changelist> > > <sha1/> > > </properties> > > > > which is obviouly wrong....(the same is if you omit the revision, > > changelist and sha1 from properties part). > > > > If you like to consume this pom file it will fail cause this can't be > > correctly solve (where is the -Drevision=2.0.0 gone?) > > > > > > That is the reason you need the flatten-maven-plugin cause it replace the > > propreties in the version tag with it's current version (can do more but > > that's a different story) and produce a correct pom file: > > > > <project xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 > > http://maven.apache.org/xsd/maven-4.0.0.xsd" xmlns=" > > http://maven.apache.org/POM/4.0.0" > > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> > > <modelVersion>4.0.0</modelVersion> > > <groupId>com.soebes.examples.j2ee</groupId> > > <artifactId>parent</artifactId> > > <version>2.0.0-SNAPSHOT</version> > > <packaging>pom</packaging> > > <licenses> > > <license> > > <name>Apache License 2.0</name> > > <url>http://www.apache.org/licenses/LICENSE-2.0.txt</url> > > <distribution>repo</distribution> > > </license> > > </licenses> > > > > which is now consumeable by any kind of tool etc. also Maven itself for > > example as a dependency.... > > > > I hope it makes this more clear... > > > > If not please ask/suggest improvements about the docs or what you need to > > know.... > > > > Kind regards > > Karl Heinz Marbaise > > > > > > > > > > > > > > > > On 08/05/17 14:29, Stephen Connolly wrote: > > > >> On Mon 8 May 2017 at 03:58, Eric Benzacar <e...@benzacar.ca> wrote: > >> > >> Hi, > >>> > >>> Interesting. Would something like this be functional then? It seems > to > >>> work, but I don't know if it is working as expected, or by fluke: > >>> > >>> <groupId>com.soebes.examples.j2ee</groupId> > >>> <artifactId>parent</artifactId> > >>> <version>${revision}</version> <packaging>pom</packaging> .. > <properties> > >>> <!-- Version --> > >>> <revision>1.2.1-${buildNumber}</revision> > >>> <buildNumber>SNAPSHOT</buildNumber> > >>> </properties> > >>> > >>> > >>> Then at the command line, I can either set the buildNumber in the case > >>> of a > >>> build: > >>> mvn installl -DbuildNumber=12345 > >>> > >>> This works, but I don't know if I am using this as designed/expected. > >>> > >> > >> > >> Nope it only *appears to work* > >> > >> If you dig deeper you will see it is not working. > >> > >> The properties *must* be provided either on the CLI or by an extension. > At > >> least as I understand it > >> > >> > >> > >>> Thanks, > >>> > >>> Eric > >>> > >>> > >>> On Sun, May 7, 2017 at 9:59 PM, Bernd Eckenfels < > e...@zusammenkunft.net> > >>> wrote: > >>> > >>> Hello, > >>>> > >>>> Only those specific properties are allowed. If I remember correctly > the > >>>> reason for it is a mixture between it is not possible to support full > >>>> property resolving in this stage of the model builder and the > intention > >>>> > >>> to > >>> > >>>> harmonize/restrict to familiarly named usecases. > >>>> > >>>> https://git-wip-us.apache.org/repos/asf?p=maven.git;a= > >>>> blobdiff;f=maven-model-builder/src/main/java/org/apache/maven/model/ > >>>> interpolation/AbstractStringBasedModelInterpolator.java;h= > >>>> > >>>> b47edbe9898b42e25e53afdfb0447ba59183f6a5;hp=cee376f1134db6d7 > >>> 8a8bd78ff9f0c7 > >>> > >>>> 108d86e448;hb=51cc76c32625be2f807dcf2ffbeb085984729b57;hpb= > >>>> 181b0215aa1199e152db9d2c08b1a01436547805 > >>>> > >>>> Gruss > >>>> Bernd > >>>> -- > >>>> http://bernd.eckenfels.net > >>>> ________________________________ > >>>> From: Eric Benzacar <e...@benzacar.ca> > >>>> Sent: Monday, May 8, 2017 3:35:46 AM > >>>> To: Maven Users List > >>>> Cc: i...@soebes.de > >>>> Subject: Re: [EXTERNAL] RE: Continuous Delivery with Maven now > possible? > >>>> > >>>> I'm confused by something in Karl's blog as well as the instructions > for > >>>> the flatten-maven-plugin and the actual release notes for Maven 3.5. > >>>> > >>>> In all the above, they talk about the ${revision}, ${sha1}, > >>>> ${changelist} > >>>> parameters. But what is so special about those particular parameters? > >>>> > >>> Can > >>> > >>>> I not use any parameter named of my choosing? > >>>> > >>>> Afterall, the ${revision} value is being set by an environment > property, > >>>> > >>> so > >>> > >>>> can I not just call it ${buildNumber} instead? > >>>> > >>>> Ex: > >>>> > >>>> <groupId>com.soebes.examples.j2ee</groupId> <artifactId>parent</ > >>>> artifactId> > >>>> <version>1.2.1-${buildNumber}</version> <packaging>pom</packaging> .. > >>>> <properties> ... <buildNumber>SNAPSHOT</buildNumber> </properties> > >>>> > >>>> > >>>> Why do I need to use ${revision}? > >>>> https://maven.apache.org/maven-ci-friendly.html specifically mentions > >>>> > >>> the > >>> > >>>> above parameters. Why? > >>>> > >>>> > >>>> Thanks, > >>>> > >>>> Eric > >>>> > >>>> > >>>> On Thu, May 4, 2017 at 9:40 PM, Justin Georgeson <jgeorge...@lgc.com> > >>>> wrote: > >>>> > >>>> Yup :) > >>>>> > >>>>> -----Original Message----- > >>>>> From: Karl Heinz Marbaise [mailto:khmarba...@gmx.de] > >>>>> Sent: Thursday, May 4, 2017 4:52 PM > >>>>> To: Justin Georgeson <jgeorge...@lgc.com>; Maven Users List < > >>>>> users@maven.apache.org>; i...@soebes.de > >>>>> Subject: Re: [EXTERNAL] RE: Continuous Delivery with Maven now > >>>>> > >>>> possible? > >>> > >>>> > >>>>> External Sender: Use caution with links/attachments. > >>>>> > >>>>> > >>>>> > >>>>> Hi, > >>>>> > >>>>> On 04/05/17 22:52, Justin Georgeson wrote: > >>>>> > >>>>>> Also I believe the partial reactor switches don't work for Tycho > >>>>>> > >>>>> builds. > >>>> > >>>>> > >>>>> You mean -pl ..option I suppose? > >>>>> > >>>>> As far as I know Tycho is handling that at the wrong time of the > maven > >>>>> build and furthermore handles in this relationship some other things > >>>>> > >>>> wrong > >>>> > >>>>> which results in not working things like this.. > >>>>> > >>>>> Kind regards > >>>>> Karl Heinz Marbaise > >>>>> > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Robert Patrick [mailto:robert.patr...@oracle.com] > >>>>>> Sent: Thursday, May 4, 2017 3:18 PM > >>>>>> To: Maven Users List <users@maven.apache.org>; i...@soebes.de > >>>>>> Subject: [EXTERNAL] RE: Continuous Delivery with Maven now possible? > >>>>>> > >>>>>> External Sender: Use caution with links/attachments. > >>>>>> > >>>>>> > >>>>>> > >>>>>> Hard to train developers to break old habits but thanks... :-) > >>>>>> > >>>>>> > >>>>>> > >>>>>> -----Original Message----- > >>>>>> From: Karl Heinz Marbaise [mailto:khmarba...@gmx.de] > >>>>>> Sent: Thursday, May 04, 2017 3:16 PM > >>>>>> To: Robert Patrick; Maven Users List; i...@soebes.de > >>>>>> Subject: Re: Continuous Delivery with Maven now possible? > >>>>>> > >>>>>> Hi Robert, > >>>>>> > >>>>>> Ah now I see the issue. > >>>>>> > >>>>>> If you have a multi module build you should use > >>>>>> > >>>>>> mvn -pl moduleToBuild clean install > >>>>>> > >>>>>> but from root location and don't change into the module directory > >>>>>> > >>>>> cause > >>> > >>>> this can't work like this. > >>>>> > >>>>>> > >>>>>> Kind regards > >>>>>> Karl Heinz Marbaise > >>>>>> > >>>>>> On 04/05/17 22:08, Robert Patrick wrote: > >>>>>> > >>>>>>> Hi Karl, > >>>>>>> > >>>>>>> If I define the revision property in the top-level POM, I cannot > >>>>>>> > >>>>>> refer > >>> > >>>> to it in the module POMs' <parent> elements *and* still retain the > >>>>> > >>>> ability > >>>> > >>>>> to build from the module directory, right? I tried this and it > failed > >>>>> because it was unable to resolve the revision property variable. > >>>>> > >>>>>> > >>>>>>> C:\rpatrick\work\projects\jcs-las\util>mvn clean install [INFO] > >>>>>>> Scanning for projects... > >>>>>>> [ERROR] [ERROR] Some problems were encountered while processing the > >>>>>>> > >>>>>> POMs: > >>>>> > >>>>>> [FATAL] Non-resolvable parent POM for > >>>>>>> oracle.jcs.lifecycle:util:[unknown-version > >>>>>>> ]: Failure to find oracle.jcs.lifecycle:app-to- > cloud:pom:${revision} > >>>>>>> in > >>>>>>> > >>>>>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__a&d=DwID > >>> aQ&c=RoP1 > >>> > >>>> Y > >>>>>>> > >>>>>>> umCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=Ql5uwmbofQMW0iErugd > >>> CnFgO-CBG > >>> > >>>> r > >>>>>>> > >>>>>>> _pt_OzwdxJosG0&m=3nZZwc0AT7pfHVI5gfXOLR0kIk5Pd5HKhazn6HJu6HY > >>> &s=by9uci > >>> > >>>> i pxSZU0-Wn16t7grG7a5Djk4ZH9440pGIayRE&e= > >>>>>>> > >>>>>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__ > rtifactory-2Dslc > >>> . > >>> > >>>> o > >>>>>>> > >>>>>>> raclecorp.com_artifactory_repo1&d=DwIFaQ&c=PskvixtEUDK7wuWU- > >>> tIg6oKuGY > >>> > >>>> B > >>>>>>> > >>>>>>> RbrMXk2FZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoEmBCjCmEi > >>> Tk&m=mQrJ > >>> > >>>> O > >>>>>>> > >>>>>>> CEKXlLF5VNECH6aqvyAu4kATrZgYUsiitvnfwY&s=oPO-3-7EEwzSMAr8-re > >>> 0YxZdReMu > >>> > >>>> 1 5_A4OMXDtdtFyA&e= was cached in the local reposito ry, resolution > >>>>>>> will not be reattempted until the update interval of repo1 has el > >>>>>>> > >>>>>> apsed > >>>> > >>>>> or updates are forced and 'parent.relativePath' points at wrong local > >>>>> > >>>> POM @ > >>>> > >>>>> line 7, column 13 @ [ERROR] The build could not read 1 project -> > >>>>> > >>>> [Help > >>> > >>>> 1] > >>>> > >>>>> [ERROR] > >>>>> > >>>>>> [ERROR] The project oracle.jcs.lifecycle:util:[unknown-version] > >>>>>>> > >>>>>> (C:\rpatrick\w > >>>>> > >>>>>> ork\projects\jcs-las\util\pom.xml) has 1 error > >>>>>>> [ERROR] Non-resolvable parent POM for > >>>>>>> > >>>>>> oracle.jcs.lifecycle:util:[ > >>> > >>>> unknown-ver > >>>>> > >>>>>> sion]: Failure to find > >>>>>>> oracle.jcs.lifecycle:app-to-cloud:pom:${revision} in http > >>>>>>> ://artifactory-slc.oraclecorp.com/artifactory/repo1 was cached in > >>>>>>> > >>>>>> the > >>> > >>>> local repo sitory, resolution will not be reattempted until the > >>>>>>> update interval of repo1 ha s elapsed or updates are forced and > >>>>>>> 'parent.relativePath' points at wrong local POM @ line 7, column 13 > >>>>>>> -> [Help 2] [ERROR] [ERROR] To see the full stack trace of the > >>>>>>> errors, re-run Maven with the -e swit ch. > >>>>>>> [ERROR] Re-run Maven using the -X switch to enable full debug > >>>>>>> > >>>>>> logging. > >>> > >>>> [ERROR] > >>>>>>> [ERROR] For more information about the errors and possible > >>>>>>> > >>>>>> solutions, > >>> > >>>> please rea d the following articles: > >>>>>>> [ERROR] [Help 1] > >>>>>>> > >>>>>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__cwiki.ap > >>> ache.org_ > >>> > >>>> c > >>>>>>> > >>>>>>> onfluence_display_MAVEN_ProjectBuildin&d=DwIDaQ&c=RoP1YumCXC > >>> gaWHvlZYR > >>> > >>>> 8 > >>>>>>> > >>>>>>> PQcxBKCX5YTpkKY057SbK10&r=Ql5uwmbofQMW0iErugdCnFgO-CBGr_pt_ > >>> OzwdxJosG0 > >>> > >>>> & > >>>>>>> > >>>>>>> m=3nZZwc0AT7pfHVI5gfXOLR0kIk5Pd5HKhazn6HJu6HY&s=Gpqh8tXn87EJ > >>> PGvORYVRo > >>> > >>>> H > >>>>>>> s2ncTiyaZSJWc3AEyEsUQ&e= > >>>>>>> gException > >>>>>>> [ERROR] [Help 2] > >>>>>>> > >>>>>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__cwiki.ap > >>> ache.org_ > >>> > >>>> c > >>>>>>> > >>>>>>> onfluence_display_MAVEN_UnresolvableMo&d=DwIDaQ&c=RoP1YumCXC > >>> gaWHvlZYR > >>> > >>>> 8 > >>>>>>> > >>>>>>> PQcxBKCX5YTpkKY057SbK10&r=Ql5uwmbofQMW0iErugdCnFgO-CBGr_pt_ > >>> OzwdxJosG0 > >>> > >>>> & > >>>>>>> > >>>>>>> m=3nZZwc0AT7pfHVI5gfXOLR0kIk5Pd5HKhazn6HJu6HY&s=kjqcy_wD0H5q > >>> wfISMGTZr > >>> > >>>> q > >>>>>>> XoHWM-jV5GAbTtEvug-bc&e= > >>>>>>> delException > >>>>>>> > >>>>>>> > >>>>>>> Did I miss something? > >>>>>>> > >>>>>>> Thanks, > >>>>>>> Robert > >>>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: Karl Heinz Marbaise [mailto:khmarba...@gmx.de] > >>>>>>> Sent: Thursday, May 04, 2017 3:02 PM > >>>>>>> To: Maven Users List > >>>>>>> Subject: Re: Continuous Delivery with Maven now possible? > >>>>>>> > >>>>>>> Hi Robert, > >>>>>>> > >>>>>>> > >>>>>>> On 04/05/17 21:55, Robert Patrick wrote: > >>>>>>> > >>>>>>> With 3.5, you can now use a variable *but* that variable > >>>>>>>> > >>>>>>> > has to be accessible to the POM prior to finding its > parent > so > >>>>>>> the only solution is to move the > version number outside the POM > >>>>>>> hierarchy and into a -D defined > >>>>>>> > >>>>>>>> variable. > >>>>>>>> > >>>>>>> > >>>>>>> Which is not true. You can define the property inside the pom file > >>>>>>> > >>>>>> if > >>> > >>>> you like and can overwrite the version via command line > >>>>> > >>>> (-Drevision=...). > >>> > >>>> > >>>>>>> > >>>>>>> > >>>>>>> > While this works, it seems to have some undesirable > aspects > to > >>>>>>> it. In my opinion, it would be better if > Maven could find a way > >>>>>>> to resolve this issue > without resorting to -Ds to specify the > > >>>>>>> value of the variable. > >>>>>>> > I am not sure it is possible but I also worry > about moving > the > >>>>>>> version number outside the POM... > >>>>>>> > >>>>>>>> > >>>>>>>> Maybe Maven should consider a mechanism by which the project > >>>>>>>> > >>>>>>> version > >>> > >>>> number can be defined in a separate location that is: > >>>>> > >>>>>> > >>>>>>>> 1.) Well-known so that all resolution can happen directly by > >>>>>>>> interacting with this location directly, without the need to > >>>>>>>> traverse the parent hierarchy > >>>>>>>> 2.) It is part of the project structure so that it can be managed > >>>>>>>> > >>>>>>> in > >>> > >>>> the project's source control system > >>>>>>>> 3.) It cannot be overridden at build time with command-line > >>>>>>>> > >>>>>>> arguments. > >>>> > >>>>> 4.) Has a mechanism by which to reference it from all the necessary > >>>>>>>> locations within the POMs > >>>>>>>> > >>>>>>>> Maybe something like an optional .mvn/project.version file and a > >>>>>>>> > >>>>>>> variable that cannot be overridden to refer to it? > >>>>> > >>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: Eric Benzacar [mailto:e...@benzacar.ca] > >>>>>>>> Sent: Thursday, May 04, 2017 12:53 PM > >>>>>>>> To: Maven Users List > >>>>>>>> Subject: Re: Continuous Delivery with Maven now possible? > >>>>>>>> > >>>>>>>> I've read through Karl's blog > >>>>>>>> ( > >>>>>>>> > >>>>>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__blog. > soebes.de_ > >>> > >>>> b > >>>>>>>> > >>>>>>>> log_&d=DwIFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10& > >>> r=Ql5uwm > >>> > >>>> b > >>>>>>>> > >>>>>>>> ofQMW0iErugdCnFgO-CBGr_pt_OzwdxJosG0&m=0Ys4DN-HQMZpvVqWFa1z9 > >>> 1pnAzKb4 > >>> > >>>> A YSpzB_W99oBqY&s=YS5dQgFEyKUuZzQgF6kuQUcPO2kUvZ3-9aUHcY3Kmmk&e= > >>>>>>>> 2017/04/02/maven-pom-files-without-a-version-in-it/), and while I > >>>>>>>> > >>>>>>> understand the approach, there is still one critical issue that > >>>>> bothers > >>>>> me. I think this actually reopens an old thread that circulated on > >>>>> > >>>> this > >>> > >>>> list a few months ago, but it related to the Idempotence of a pom > file. > >>>>> > >>>>>> > >>>>>>>> >From my perspective/view a pom file should be idempotent. That > is > >>>>>>>> > >>>>>>> every single build of a given NON-SNAPSHOT pom file should finish > >>>>> with > >>>>> > >>>> the > >>>> > >>>>> same build. But by moving a release number or version number outside > >>>>> > >>>> of > >>> > >>>> the pom, it eliminates this need. Furthermore, from a traceability > >>>>> perspective, my source control can no longer show me precisely > version > >>>>> > >>>> was > >>>> > >>>>> being built/developed at any given time. > >>>>> > >>>>>> > >>>>>>>> By leveraging the mvn.config file, I'm a little further down the > >>>>>>>> > >>>>>>> path, > >>>> > >>>>> but none the less, the value can be overridden at build time with a > >>>>> completely different value. Consequently, I can still not be 100% > >>>>> confident that a pom delivered a particular version. > >>>>> > >>>>>> > >>>>>>>> I'm still not 100% sure of the best approach going forward, but > I'm > >>>>>>>> > >>>>>>> thinking that something like the version-plugin being able to > >>>>> > >>>> manipulate > >>> > >>>> a > >>>> > >>>>> revision property that can then be committed as part of the pom would > >>>>> > >>>> be > >>> > >>>> the best of both approaches. In that way, my developers can fix the > >>>>> version number, but my build system can manipulate the revision > >>>>> > >>>> property. > >>> > >>>> > >>>>>>>> Does anyone know if there is a plugin that will allow for that? > >>>>>>>> > >>>>>>>> Thanks, > >>>>>>>> > >>>>>>>> Eric > >>>>>>>> > >>>>>>>> > >>>>>>>> On Thu, May 4, 2017 at 12:40 PM, Thomas Broyer < > https://urldefense > >>>>>>>> > >>>>>>> . > >>> > >>>> proofpoint.com/v2/url?u=http-3A__t.broyer-40gmail.com&d= > >>>>> DwIFaQ&c=PskvixtEUDK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo&r= > >>>>> dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoEmBCjCmEiTk&m= > >>>>> mQrJOCEKXlLF5VNECH6aqvyAu4kATrZgYUsiitvnfwY&s= > >>>>> 0PY7XDt7qFb0WfiWMn1CIgxZ2Q6apBhIlOqIgfU0A3A&e= > wrote: > >>>>> > >>>>>> > >>>>>>>> How about everybody read their mail? > >>>>>>>>> (see below) > >>>>>>>>> > >>>>>>>>> On Thu, May 4, 2017 at 6:10 PM Curtis Rueden <ctrue...@wisc.edu> > >>>>>>>>> > >>>>>>>> wrote: > >>>>> > >>>>>> > >>>>>>>>> Hi Dan, Karl & everyone, > >>>>>>>>>> > >>>>>>>>>> See Karl's Blog > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> Link, please? > >>>>>>>>>> > >>>>>>>>>> [...] > >>>>>>>>> > >>>>>>>>> On 03/05/17 20:39, Dan Tran wrote: > >>>>>>>>>>>>> > >>>>>>>>>>>>> Hi > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> I have been experimenting with suggestion from Karl [1] with > >>>>>>>>>>>>>> small > >>>>>>>>>>>>>> > >>>>>>>>>>>>> multi > >>>>>>>>>>> > >>>>>>>>>>>> module maven project. > >>>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>> [...] > >>>>>>>>> > >>>>>>>>> [1] > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__blog. > soeb > >>> > >>>> es.de_blog_2017_04_02_maven-2Dpom-2Dfiles-2Dwithou&d=DwIFaQ&c > >>>>>>>>>>>>>> =RoP1YumCXCgaWHvlZYR8PQcxBKCX5Y > TpkKY057SbK10&r=Ql5uwmbofQMW0i > >>>>>>>>>>>>>> ErugdCnFgO-CBGr_pt_OzwdxJosG0&m=0Ys4DN- > HQMZpvVqWFa1z91pnAzKb4 > >>>>>>>>>>>>>> AYSpzB_W99oBqY&s=RYXyGU3piqrAe7XDXXTuPvbcQH935s > duSNhMeYstT8Y& > >>>>>>>>>>>>>> e= > >>>>>>>>>>>>>> t-a-version-in-it/ > >>>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>> > >>>>> ------------------------------------------------------------ > ---------- > >>>>> This e-mail, including any attached files, may contain confidential > and > >>>>> privileged information for the sole use of the intended recipient. > Any > >>>>> review, use, distribution, or disclosure by others is strictly > >>>>> > >>>> prohibited. > >>>> > >>>>> If you are not the intended recipient (or authorized to receive > >>>>> > >>>> information > >>>> > >>>>> for the intended recipient), please contact the sender by reply > e-mail > >>>>> > >>>> and > >>>> > >>>>> delete all copies of this message. > >>>>> > >>>>> > >>>> > >>> > > > > Mit freundlichem Gru? > > Karl-Heinz Marbaise > > -- > > SoftwareEntwicklung Beratung Schulung Tel.: +49 (0) 2405 / 415 893 > > Dipl.Ing.(FH) Karl-Heinz Marbaise USt.IdNr: DE191347579 > > Hauptstrasse 177 > > 52146 W?rselen http://www.soebes.de > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > > For additional commands, e-mail: users-h...@maven.apache.org > > > > >