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=cee376f1134db6d78a8bd78ff9f0c7108d86e448;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=DwIDaQ&c=RoP1 > >> Y > >> umCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=Ql5uwmbofQMW0iErugdCnFgO-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_OVZL1uyui4QoEmBCjCmEiTk&m=mQrJ > >> O > >> CEKXlLF5VNECH6aqvyAu4kATrZgYUsiitvnfwY&s=oPO-3-7EEwzSMAr8-re0YxZdReMu > >> 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.apache.org_ > >> c > >> onfluence_display_MAVEN_ProjectBuildin&d=DwIDaQ&c=RoP1YumCXCgaWHvlZYR > >> 8 > >> PQcxBKCX5YTpkKY057SbK10&r=Ql5uwmbofQMW0iErugdCnFgO-CBGr_pt_OzwdxJosG0 > >> & > >> m=3nZZwc0AT7pfHVI5gfXOLR0kIk5Pd5HKhazn6HJu6HY&s=Gpqh8tXn87EJPGvORYVRo > >> H > >> s2ncTiyaZSJWc3AEyEsUQ&e= > >> gException > >> [ERROR] [Help 2] > >> https://urldefense.proofpoint.com/v2/url?u=http-3A__cwiki.apache.org_ > >> c > >> onfluence_display_MAVEN_UnresolvableMo&d=DwIDaQ&c=RoP1YumCXCgaWHvlZYR > >> 8 > >> PQcxBKCX5YTpkKY057SbK10&r=Ql5uwmbofQMW0iErugdCnFgO-CBGr_pt_OzwdxJosG0 > >> & > >> m=3nZZwc0AT7pfHVI5gfXOLR0kIk5Pd5HKhazn6HJu6HY&s=kjqcy_wD0H5qwfISMGTZr > >> 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-HQMZpvVqWFa1z91pnAzKb4 > >>> 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 > >>>>>>>>> =RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=Ql5uwmbofQMW0i > >>>>>>>>> ErugdCnFgO-CBGr_pt_OzwdxJosG0&m=0Ys4DN-HQMZpvVqWFa1z91pnAzKb4 > >>>>>>>>> AYSpzB_W99oBqY&s=RYXyGU3piqrAe7XDXXTuPvbcQH935sduSNhMeYstT8Y& > >>>>>>>>> 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. >