It's not just that (although that is a very good reason). Maven can't interpolate variables in a pom file until it has constructed the effective pom and effective settings. But it can't construct the effective pom if there are variables in the parent declaration. So having a variable in the parent declaration can't work, it's a catch 22 situation.
On Tue, Mar 29, 2016 at 3:25 PM, Paul Munsey <paul.mun...@verifone.com> wrote: > 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:mehul.sang...@gmail.com] > 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 < > stephen.alan.conno...@gmail.com> 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 < > > stephen.alan.conno...@gmail.com> > > 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 <bimargul...@gmail.com > > > <javascript:_e(%7B%7D,'cvml','bimargul...@gmail.com');>> 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 > > >> <bimargul...@gmail.com > > > > > >> 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 < > > bimargul...@gmail.com> > > >> 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 < > > >> bimargul...@gmail.com> wrote: > > >> >>> On Wed, Mar 9, 2016 at 3:20 PM, Stephen Connolly > > >> >>> <stephen.alan.conno...@gmail.com> wrote: > > >> >>>> On Wednesday, 9 March 2016, Benson Margulies < > > bimargul...@gmail.com> > > >> wrote: > > >> >>>> > > >> >>>>> On Wed, Mar 9, 2016 at 8:51 AM, Tamás Cservenák < > > >> ta...@cservenak.net > > >> >>>>> <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 < > > >> >>>>> > stephen.alan.conno...@gmail.com <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 < > > >> bimargul...@gmail.com > > >> >>>>> <javascript:;>> wrote: > > >> >>>>> >> > > >> >>>>> >> > On Tue, Mar 8, 2016 at 2:28 PM, Stephen Connolly > > >> >>>>> >> > <stephen.alan.conno...@gmail.com <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 < > > >> garydgreg...@gmail.com > > >> >>>>> <javascript:;>> wrote: > > >> >>>>> >> > > > > >> >>>>> >> > >> On Mon, Mar 7, 2016 at 6:53 PM, Eric B < > > ebenza...@gmail.com > > >> >>>>> <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 < > > >> >>>>> >> garydgreg...@gmail.com <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 < > > >> ebenza...@gmail.com > > >> >>>>> <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 < stephen.alan.conno...@gmail.com > > >> >>>>> >> > >> > > > <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 < > > >> raghunath...@yahoo.com > > >> >>>>> <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: garydgreg...@gmail.com <javascript:;> > > >> <javascript:;> | > > >> >>>>> >> ggreg...@apache.org <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: garydgreg...@gmail.com <javascript:;> > > >> <javascript:;> | > > >> >>>>> ggreg...@apache.org <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: > > >> >>>>> >> > users-unsubscr...@maven.apache.org > > >> >>>>> <javascript:;> > > >> >>>>> >> > For additional commands, e-mail: > > >> >>>>> >> > users-h...@maven.apache.org > > >> >>>>> <javascript:;> > > >> >>>>> >> > > > >> >>>>> >> > > > >> >>>>> >> > > >> >>>>> > > >> >>>>> > > >> ------------------------------------------------------------------- > > >> -- > > >> >>>>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > > >> <javascript:;> > > >> >>>>> For additional commands, e-mail: users-h...@maven.apache.org > > >> >>>>> <javascript:;> > > >> >>>>> > > >> >>>>> > > >> >>>> > > >> >>>> -- > > >> >>>> Sent from my phone > > >> > > >> ------------------------------------------------------------------- > > >> -- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > > >> For additional commands, e-mail: users-h...@maven.apache.org > > >> > > >> > > > > > > -- > > > Sent from my phone > > > > > > > > > -- > > Sent from my phone > > > > > > -- > Mehul N. Sanghvi > email: mehul.sang...@gmail.com >
