I think people are misunderstanding part of the reason for the <version> within a pom.xml file. Yes, that version is used to version the artifact, but it is also used to uniquely identify the pom.xml file. Suppose I change my pom.xml (ex. add a new dependency); if my <version> is defined by a variable, it won't change when my pom.xml file changes, then how do I know which version of the pom.xml had, or didn't have, that extra dependency?
I believe this is why Maven gives the message: [WARNING] 'version' contains an expression but should be a constant. I live by the rule that if anything in my pom.xml file changes, I must bump the version. Yes that's a pain especially if it is a parent pom.xml (because then it ripples down into all children and grandchildren), but that's the price to pay for guaranteeing that I know exactly how I produced my artifacts. Regards, Paul -----Original Message----- From: Mehul Sanghvi [mailto:[email protected]] Sent: Tuesday, March 29, 2016 8:03 AM To: Maven Users List Subject: Re: variable doesn't work for version I am guessing that is what is happening in my case. We have a multi-module project, and so the root POM has the following for the project: <project ..... > <groupId>com.mehul</groupId> <artifactId>super-project</artifactId> <packaging>pom</packaging> <versioning>${revision}</version> .... </project> In sub-module-A/pom.xml: <project ....> <parent> <groupId>com.mehul</groupId> <artifactId>super-project</artifactId> <version>${revision}</version> </parent> <groupId>com.mehul</groupId> <artifactId>sub-module-A</artifactId> .... </project> In sub-module-A/sub-AA/pom.xml <project ....> <parent> <groupId>com.mehul</groupId> <artifactId>sub-module-A</artifactId> <version>${revision}</version> </parent> <groupId>com.mehul</groupId> <artifactId>sub-AA-maven-plugin</artifactId> <packaging>maven-plugin</packaging> .... </project> sub-AA-maven-plugin is required before the project can be built, so I do the following steps in order to get the over-all project built: bash% cd sub-module-A bash% mvn -Drevision=1.2.3.4.5-SNAPSHOT -B -V clean install bash% cd .. bash% mvn -Drevision=1.2.3.4.5-SNAPSHOT -B -V clean install Everything gets built, but when I look at the ~/.m2/repository/com/mehul/sub-module-A/1.2.3.4.5-SNAPSHOT/sub-module-A-1.2.3.4.5-SNAPSHOT.pom file, the version is not substituted with 1.2.3.4.5-SNAPSHOT, but rather still has the ${revision} property, verbatim. Is this expected behaviour or is this a bug? Is this what is being talked about when saying this doesn't fully include logic to ensure that the substitution resolved pom is installed/deployed, so may cause issues for out-of-reactor consumption as a dependency I do get dependency related issues when trying to use sub-AA-maven-plugin in the build process. The failure is of the following type: No plugin found for prefix 'sub-AA' in the current project and in the plugin groups ... If I use an explicit version number in the POM files, everything works just fine. Also if I use plugin with full GAV resolution from the command line: mvn com.mehul:sub-AA-maven-plugin:1.2.3.4.5-SNAPSHOT:do-fubar it works just fine. Normally I would use the plug-in using the following: mvn sub-AA:do-fubar and nothing more. Apologies if this is not related to the issue at hand. I was reading through this thread and it seemed what was being talked about was similar to my issue. cheers, mehul On Thu, Mar 10, 2016 at 3:04 AM, Stephen Connolly < [email protected]> wrote: > Also I suspect this doesn't fully include logic to ensure that the > substitution resolved pom is installed/deployed, so may cause issues > for out-of-reactor consumption as a dependency, or GPG signature > validation if you try to "fix" with a hack > > On Thursday 10 March 2016, Stephen Connolly < > [email protected]> > wrote: > > > It's ${revision} or ${changelist} or a third one I cannot recall, > > ${rev} is on the "moan and wail" list > > > > On Wednesday 9 March 2016, Benson Margulies <[email protected] > > <javascript:_e(%7B%7D,'cvml','[email protected]');>> wrote: > > > >> Almost really working. The only gripe is that it is still warning > >> me that I have an expression in <version/>, even when I use 'rev' > >> as cited. Is that poor choice? > >> > >> [INFO] rev 0.0.1.20160309172035 > >> [INFO] Scanning for projects... > >> [WARNING] > >> [WARNING] Some problems were encountered while building the > >> effective model for > >> com.basistech:auto-version-maven-extension-test:jar:0.0.1.201603091 > >> 72035 [WARNING] 'version' contains an expression but should be a > >> constant. @ com.basistech:auto-version-maven-extension-test:${rev}, > >> /Users/benson/x/auto-version-maven-extension/src/it/basic/pom.xml, > >> line 7, column 14 > >> [WARNING] > >> [WARNING] It is highly recommended to fix these problems because > >> they threaten the stability of your build. > >> [WARNING] > >> [WARNING] For this reason, future Maven versions might no longer > >> support building such malformed projects. > >> [WARNING] > >> > >> > >> > >> On Wed, Mar 9, 2016 at 5:14 PM, Benson Margulies > >> <[email protected] > > > >> wrote: > >> > Of course, as soon as I hit Send I found out what I screwed up. > >> > > >> > On Wed, Mar 9, 2016 at 5:12 PM, Benson Margulies < > [email protected]> > >> wrote: > >> >> I tried this and it didn't work, even a little. > >> >> > >> >> See https://github.com/benson-basis/auto-version-maven-extension. > >> >> > >> >> My extension is never called, whether I put it into .mvn or the > >> >> maven home lib/ext directory. (Proved by running mvnDebug, > >> >> setting a breakpoint, and attaching a debugger). > >> >> > >> >> > >> >> > >> >> On Wed, Mar 9, 2016 at 3:24 PM, Benson Margulies < > >> [email protected]> wrote: > >> >>> On Wed, Mar 9, 2016 at 3:20 PM, Stephen Connolly > >> >>> <[email protected]> wrote: > >> >>>> On Wednesday, 9 March 2016, Benson Margulies < > [email protected]> > >> wrote: > >> >>>> > >> >>>>> On Wed, Mar 9, 2016 at 8:51 AM, Tamás Cservenák < > >> [email protected] > >> >>>>> <javascript:;>> wrote: > >> >>>>> > I assume it should be this (instead of spy): > >> >>>>> > > >> http://maven.apache.org/examples/maven-3-lifecycle-extensions.html > >> >>>>> > > >> >>>>> > And instead of starting beer machine, it can inject the > >> >>>>> > value > >> into the > >> >>>>> > session that you got from whenever... > >> >>>>> > >> >>>>> I don't think this can work as a thing configured in the POM. > Unless > >> >>>>> these items can be dropped into the ext directory instead of > >> >>>>> configured in the the pom as an extension. Is that the case > >> >>>>> in > >> general > >> >>>>> that the ext dir is the same thing as declaring in the POM as > >> >>>>> an extension? > >> >>>> > >> >>>> > >> >>>> That's where the .mvn folder as an extension loading mechanism > kicks > >> in > >> >>> > >> >>> What version did that show up in? Prior, it has to be in a dir > >> >>> in > the > >> >>> maven home, right? > >> >>> > >> >>>> > >> >>>> > >> >>>>> > >> >>>>> > >> >>>>> > > >> >>>>> > maven related changes merely laxed the validation to allow > >> >>>>> > those > >> three > >> >>>>> > expressions in version, but does not provide anything as > "source" > >> for > >> >>>>> those. > >> >>>>> > > >> >>>>> > On Wed, Mar 9, 2016 at 2:44 PM Stephen Connolly < > >> >>>>> > [email protected] <javascript:;>> wrote: > >> >>>>> > > >> >>>>> >> I have no clue... that is a different question we should > >> >>>>> >> ask of > >> the > >> >>>>> person > >> >>>>> >> who implemented this functionality > >> >>>>> >> > >> >>>>> >> On 9 March 2016 at 13:40, Benson Margulies < > >> [email protected] > >> >>>>> <javascript:;>> wrote: > >> >>>>> >> > >> >>>>> >> > On Tue, Mar 8, 2016 at 2:28 PM, Stephen Connolly > >> >>>>> >> > <[email protected] <javascript:;>> wrote: > >> >>>>> >> > > In the .mvn folder put an extension that contributes > >> >>>>> >> > > the > >> ${rev} > >> >>>>> >> property > >> >>>>> >> > > based on whatever you seem safe > >> >>>>> >> > > >> >>>>> >> > Stephen, can you please offer some details? Just what > >> >>>>> >> > sort of extension? An event spy that sees session start? > >> >>>>> >> > Something > >> else? Does > >> >>>>> >> > this require 3.3.x or does it work with 3.2.5? > >> >>>>> >> > > >> >>>>> >> > > > >> >>>>> >> > > Then just have the project version include the ${rev} > >> >>>>> >> > > at > the > >> >>>>> >> appropriate > >> >>>>> >> > > place > >> >>>>> >> > > > >> >>>>> >> > > On Tuesday 8 March 2016, Gary Gregory < > >> [email protected] > >> >>>>> <javascript:;>> wrote: > >> >>>>> >> > > > >> >>>>> >> > >> On Mon, Mar 7, 2016 at 6:53 PM, Eric B < > [email protected] > >> >>>>> <javascript:;> > >> >>>>> >> > <javascript:;>> > >> >>>>> >> > >> wrote: > >> >>>>> >> > >> > >> >>>>> >> > >> > The first question I have to ask is what you are > >> >>>>> >> > >> > trying > to > >> >>>>> >> accomplish > >> >>>>> >> > >> with > >> >>>>> >> > >> > your continuous-delivery? > >> >>>>> >> > >> > >> >>>>> >> > >> > >> >>>>> >> > >> We have a Maven multi-module build which has > >> >>>>> >> > >> thousands of > >> unit > >> >>>>> tests. > >> >>>>> >> We > >> >>>>> >> > >> use Bamboo for CI and if we get a green build that > >> >>>>> >> > >> means > >> that all > >> >>>>> the > >> >>>>> >> > tests > >> >>>>> >> > >> pass of course and that we successfully deployed the > >> >>>>> >> > >> build > >> to our > >> >>>>> repo > >> >>>>> >> > (we > >> >>>>> >> > >> use Artifactory). We use the Maven's deploy to > >> >>>>> >> > >> deploy, not > >> the > >> >>>>> release > >> >>>>> >> > >> plugin. > >> >>>>> >> > >> > >> >>>>> >> > >> At this point anyone can use the built product out of > >> Bamboo's > >> >>>>> saved > >> >>>>> >> > >> artifacts or Artifactory: our internal/external > >> consultants, sales > >> >>>>> >> > >> engineers, formal QA, other downstream, products, and > >> >>>>> >> > >> so > >> on. It's > >> >>>>> up > >> >>>>> >> to > >> >>>>> >> > the > >> >>>>> >> > >> PO to decide when to slap a new major or minor > >> >>>>> >> > >> version > >> label and > >> >>>>> >> he/she > >> >>>>> >> > can > >> >>>>> >> > >> do at anytime. > >> >>>>> >> > >> > >> >>>>> >> > >> From development's POV, a green build is a released > >> product, with a > >> >>>>> >> > version > >> >>>>> >> > >> for example 3.1.201601070101 (3.1.YYYYMMDDHHMM). We > >> >>>>> >> > >> used > to > >> have > >> >>>>> the > >> >>>>> >> SVN > >> >>>>> >> > >> version number as the maintenance version part but we > >> >>>>> >> > >> are > >> >>>>> switching to > >> >>>>> >> > Git > >> >>>>> >> > >> soon, hence the move to timestamps. > >> >>>>> >> > >> > >> >>>>> >> > >> Our parent POM contains what is considered a Maven "hack": > >> >>>>> >> > >> > >> >>>>> >> > >> <properties> > >> >>>>> >> > >> > >> >>>>> >> > >> > >> >>>>> >> > > >> >>>>> > >> > <maven.build.timestamp.format>yyyyMMddHHmm</maven.build.timestamp.form > at> > >> >>>>> >> > >> <version.major>3</version.major> > >> >>>>> >> > >> <version.minor>1</version.minor> > >> >>>>> >> > >> > >> <version.main>${version.major}.${version.minor}</version.main> > >> >>>>> >> > >> <revision>${maven.build.timestamp}</revision> > >> >>>>> >> > >> > >> >>>>> >> > >> <dv.version>${version.main}.${revision}</dv.version> > >> >>>>> >> > >> > >> >>>>> >> > >> Each module then has: > >> >>>>> >> > >> > >> >>>>> >> > >> <version>${dv.version}</version> > >> >>>>> >> > >> > >> >>>>> >> > >> What is the Maven way to achieve this goal? > >> >>>>> >> > >> > >> >>>>> >> > >> Gary > >> >>>>> >> > >> > >> >>>>> >> > >> > >> >>>>> >> > >> > >> >>>>> >> > >> > Are you trying to put snapshot versions into a > >> >>>>> >> > >> > production/release state? > >> >>>>> >> > >> > > >> >>>>> >> > >> > The biggest issue I have noticed with teams is the > >> >>>>> misunderstanding > >> >>>>> >> of > >> >>>>> >> > >> how > >> >>>>> >> > >> > SNAPSHOTs work, or their purpose in the development > >> process. > >> >>>>> Either > >> >>>>> >> > >> teams > >> >>>>> >> > >> > want to release applications in SNAPSHOT mode, or > release > >> code > >> >>>>> that > >> >>>>> >> is > >> >>>>> >> > >> > essentially in SNAPSHOT (ie: development) mode, but > >> >>>>> >> > >> > with > >> fixed > >> >>>>> >> version > >> >>>>> >> > >> > numbers. But instead of changing version numbers, > >> >>>>> >> > >> > they > >> use > >> >>>>> >> something > >> >>>>> >> > >> like > >> >>>>> >> > >> > a timestamp to increment version numbers automatically. > >> But at > >> >>>>> the > >> >>>>> >> > end > >> >>>>> >> > >> of > >> >>>>> >> > >> > it all, it kind of contravenes maven's versioning > concept. > >> >>>>> >> > >> > > >> >>>>> >> > >> > Normally, if your artifact is a work in progress, > >> >>>>> >> > >> > you > >> should > >> >>>>> just be > >> >>>>> >> > >> using > >> >>>>> >> > >> > a SNAPSHOT. If you are looking to make a real > >> >>>>> >> > >> > release, > >> then you > >> >>>>> >> > should > >> >>>>> >> > >> be > >> >>>>> >> > >> > promoting your code from a SNAPSHOT to a fixed version. > >> >>>>> Generally, > >> >>>>> >> > the > >> >>>>> >> > >> > concept of continuous-delivery should only apply > >> >>>>> >> > >> > when > in a > >> >>>>> SNAPSHOT > >> >>>>> >> > mode, > >> >>>>> >> > >> > since anything else isn't changing (ie: a fixed > >> >>>>> >> > >> > release > >> doesn't > >> >>>>> need > >> >>>>> >> > to > >> >>>>> >> > >> be > >> >>>>> >> > >> > re-delivered). > >> >>>>> >> > >> > > >> >>>>> >> > >> > So then that begs the question why you need to > constantly > >> change > >> >>>>> >> your > >> >>>>> >> > >> > version numbers during your development phase? > >> >>>>> >> > >> > > >> >>>>> >> > >> > And if the goal is truly to have fixed versions for > >> >>>>> >> > >> > some > >> other > >> >>>>> team > >> >>>>> >> to > >> >>>>> >> > >> have > >> >>>>> >> > >> > access to a "stable" version of your artifact (ie: > >> >>>>> >> > >> > they > >> can be > >> >>>>> >> > guaranteed > >> >>>>> >> > >> > that it isn't going to change as you continue to > >> develop), you > >> >>>>> could > >> >>>>> >> > >> always > >> >>>>> >> > >> > use something like the maven-release-plugin to > >> >>>>> >> > >> > promote > >> from > >> >>>>> SNAPSHOT > >> >>>>> >> > to a > >> >>>>> >> > >> > fixed version, and then re-open the next version as > >> >>>>> >> > >> > a > >> SNAPSHOT. > >> >>>>> >> > >> (Although > >> >>>>> >> > >> > I know there are many dissenters against the > >> release-plugin). > >> >>>>> >> > >> > > >> >>>>> >> > >> > Thanks, > >> >>>>> >> > >> > > >> >>>>> >> > >> > Eric > >> >>>>> >> > >> > > >> >>>>> >> > >> > > >> >>>>> >> > >> > > >> >>>>> >> > >> > On Mon, Mar 7, 2016 at 7:15 PM, Gary Gregory < > >> >>>>> >> [email protected] <javascript:;> > >> >>>>> >> > >> <javascript:;>> > >> >>>>> >> > >> > wrote: > >> >>>>> >> > >> > > >> >>>>> >> > >> > > Is there a Maven-way to do continuous delivery then? > As > >> opposed > >> >>>>> >> > >> > > to continuous integration. > >> >>>>> >> > >> > > > >> >>>>> >> > >> > > Our current hack is to use the date as the > >> >>>>> >> > >> > > maintenance > >> version > >> >>>>> as > >> >>>>> >> a > >> >>>>> >> > >> > > variable for example 3.1.20160102 > >> >>>>> >> > >> > > > >> >>>>> >> > >> > > G > >> >>>>> >> > >> > > > >> >>>>> >> > >> > > On Mon, Mar 7, 2016 at 11:18 AM, Eric B < > >> [email protected] > >> >>>>> <javascript:;> > >> >>>>> >> > >> <javascript:;>> wrote: > >> >>>>> >> > >> > > > >> >>>>> >> > >> > > > I personally have a pet-peeve of using system > >> variables to > >> >>>>> >> define > >> >>>>> >> > >> > version > >> >>>>> >> > >> > > > numbers; I find it is counter productive to the > >> building of > >> >>>>> >> maven > >> >>>>> >> > >> > > > artifacts. There is no traceability to > >> >>>>> >> > >> > > > determine > >> the actual > >> >>>>> >> > version > >> >>>>> >> > >> > of > >> >>>>> >> > >> > > an > >> >>>>> >> > >> > > > artifact once it has been built. At least > >> >>>>> >> > >> > > > having a > >> fixed > >> >>>>> >> version > >> >>>>> >> > >> > number > >> >>>>> >> > >> > > in > >> >>>>> >> > >> > > > the <version> element shows up in the > >> META-INF/maven/../pom.* > >> >>>>> >> > files. > >> >>>>> >> > >> > > > > >> >>>>> >> > >> > > > Is using a variable for the version even a good > idea? > >> >>>>> >> > >> > > > > >> >>>>> >> > >> > > > Thanks, > >> >>>>> >> > >> > > > > >> >>>>> >> > >> > > > Eric > >> >>>>> >> > >> > > > > >> >>>>> >> > >> > > > > >> >>>>> >> > >> > > > On Mon, Mar 7, 2016 at 4:04 AM, Stephen > >> >>>>> >> > >> > > > Connolly < [email protected] > >> >>>>> >> > >> > > > <javascript:;> > >> >>>>> <javascript:;>> wrote: > >> >>>>> >> > >> > > > > >> >>>>> >> > >> > > > > only specific properties are permitted for > >> expansion in > >> >>>>> XPath > >> >>>>> >> > paths > >> >>>>> >> > >> > > that > >> >>>>> >> > >> > > > > match the following regex > >> >>>>> >> > >> > > /project/(parent/)?(groupId|artifactId|version) > >> >>>>> >> > >> > > > > > >> >>>>> >> > >> > > > > On 2 March 2016 at 05:39, Raghu < > >> [email protected] > >> >>>>> <javascript:;> > >> >>>>> >> .invalid > >> >>>>> >> > > > >> >>>>> >> > >> > > wrote: > >> >>>>> >> > >> > > > > > >> >>>>> >> > >> > > > > > I have a POM with parent node as below: > >> >>>>> >> > >> > > > > > <parent> <groupId>com.test</groupId> > >> >>>>> >> > <artifactId>pom.parent</artifactId> > >> >>>>> >> > >> > > > > > <version>${test.version}</version> > >> >>>>> >> > >> > > > > > <relativePath>../scripts/pom.xml</relativeP > >> >>>>> >> > >> > > > > > ath> > >> </parent> > >> >>>>> >> > >> > > > > > This used to work till maven 3.3.3 version > >> >>>>> >> > >> > > > > > - mvn > >> clean > >> >>>>> >> > install. > >> >>>>> >> > >> > > > However, > >> >>>>> >> > >> > > > > > the version 3.3.9 throws error though. When > >> >>>>> >> > >> > > > > > I > >> change the > >> >>>>> >> > version > >> >>>>> >> > >> > to a > >> >>>>> >> > >> > > > > value > >> >>>>> >> > >> > > > > > instead of the variable, it works fine. > >> >>>>> >> > >> > > > > > Won't maven support variable for version? > >> >>>>> >> > >> > > > > > Or is > >> it a bug > >> >>>>> >> with > >> >>>>> >> > >> > 3.3.9? > >> >>>>> >> > >> > > > > > Appreciate your response... > >> >>>>> >> > >> > > > > > - regards,raghu > >> >>>>> >> > >> > > > > > >> >>>>> >> > >> > > > > >> >>>>> >> > >> > > > >> >>>>> >> > >> > > > >> >>>>> >> > >> > > > >> >>>>> >> > >> > > -- > >> >>>>> >> > >> > > E-Mail: [email protected] <javascript:;> > >> <javascript:;> | > >> >>>>> >> [email protected] <javascript:;> > >> >>>>> >> > >> <javascript:;> > >> >>>>> >> > >> > > Java Persistence with Hibernate, Second Edition > >> >>>>> >> > >> > > <http://www.manning.com/bauer3/> JUnit in Action, > >> >>>>> >> > >> > > Second Edition < > >> >>>>> http://www.manning.com/tahchiev/ > >> >>>>> >> > > >> >>>>> >> > >> > > Spring Batch in Action < > >> http://www.manning.com/templier/> > >> >>>>> >> > >> > > Blog: http://garygregory.wordpress.com > >> >>>>> >> > >> > > Home: http://garygregory.com/ Tweet! > >> >>>>> >> > >> > > http://twitter.com/GaryGregory > >> >>>>> >> > >> > > > >> >>>>> >> > >> > > >> >>>>> >> > >> > >> >>>>> >> > >> > >> >>>>> >> > >> > >> >>>>> >> > >> -- > >> >>>>> >> > >> E-Mail: [email protected] <javascript:;> > >> <javascript:;> | > >> >>>>> [email protected] <javascript:;> > >> >>>>> >> > >> <javascript:;> > >> >>>>> >> > >> Java Persistence with Hibernate, Second Edition > >> >>>>> >> > >> <http://www.manning.com/bauer3/> JUnit in Action, > >> >>>>> >> > >> Second Edition < > >> http://www.manning.com/tahchiev/> > >> >>>>> >> > >> Spring Batch in Action > >> >>>>> >> > >> <http://www.manning.com/templier/> > >> >>>>> >> > >> Blog: http://garygregory.wordpress.com > >> >>>>> >> > >> Home: http://garygregory.com/ Tweet! > >> >>>>> >> > >> http://twitter.com/GaryGregory > >> >>>>> >> > >> > >> >>>>> >> > > > >> >>>>> >> > > > >> >>>>> >> > > -- > >> >>>>> >> > > Sent from my phone > >> >>>>> >> > > >> >>>>> >> > > >> ------------------------------------------------------------------- > >> -- > >> >>>>> >> > To unsubscribe, e-mail: > >> >>>>> >> > [email protected] > >> >>>>> <javascript:;> > >> >>>>> >> > For additional commands, e-mail: > >> >>>>> >> > [email protected] > >> >>>>> <javascript:;> > >> >>>>> >> > > >> >>>>> >> > > >> >>>>> >> > >> >>>>> > >> >>>>> > >> ------------------------------------------------------------------- > >> -- > >> >>>>> To unsubscribe, e-mail: [email protected] > >> <javascript:;> > >> >>>>> For additional commands, e-mail: [email protected] > >> >>>>> <javascript:;> > >> >>>>> > >> >>>>> > >> >>>> > >> >>>> -- > >> >>>> Sent from my phone > >> > >> ------------------------------------------------------------------- > >> -- To unsubscribe, e-mail: [email protected] > >> For additional commands, e-mail: [email protected] > >> > >> > > > > -- > > Sent from my phone > > > > > -- > Sent from my phone > -- Mehul N. Sanghvi email: [email protected]
