also trace back to my note on this thread, I use buildnumber-m-p for build
definition and traceability purpose
-D
On Tue, May 9, 2017 at 7: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
> >
> >
>
