Why dont you use the buildnumber plugin? That might be able to do it for you..
http://mojo.codehaus.org/buildnumber-maven-plugin/ > For what it's worth, I agree with you both (version strings should be > controlled via the -ahem- version control system), but I am willing to > allow Maven (more to the point, the maven-release-plugin) to take care > of the version strings for me. > > However, if you don't want to, you can still do it yourself with Maven > 3 ... but you *can't* do it with properties at the command-line; you > *will* need to update the poms. Just do it outside of maven before > you perform the final build - should not be hard. If doing that is > too much to ask ... then, yeah, Maven may not be the right framework > for you. But consider that you will need to do *something* similar -- > either you write your own around maven, or you write your own around > some other system. > > On Tue, May 17, 2011 at 11:12 AM, Russ Tremain <[email protected]> > wrote: >> +1. >> >> this is the major reason I won't be upgrading to maven 3. >> >> I do think that versions should be fixed at maven deploy time - i.e., >> when artifacts are deployed to the repository. >> >> -Russ >> >> At 5:21 AM -0700 3/26/11, bryan.dollery wrote: >>>Hi, >>> >>>I am also getting grief from maven for using variables in my version >>> fields. >>>For me, this is unavoidable. Let me explain... >>> >>>In my parent pom I have: >>> >>>${productVersion} >>> >>>And in my properties I have: >>> >>> 0-SNAPSHOT >>> 13.0.${productRevision} >>> >>>On a developer's machine, this produces a version number of >>> >>> 13.0.0-SNAPSHOT >>> >>>Which is exactly what I want. >>> >>>However, in my hudson CI server, as part of the maven command I have: >>> >>> -DivpnRevision=$SVN_REVISION-nt3 >>> >>>The $SVN_REVISION variable is provided by hudson. It contains the svn >>>revision number that has just been built, and the '-nt3' bit is the >>>environment it was built for. >>> >>>I do this because subversion is my revision control system and it, >>> rightly, >>>controls the revision number (the clue as to it's purpose is in it's >>> name). >>>This is not a job I want to hand off to maven, for many reasons. >>> >>>If I use maven 3 for my builds, then my IDEs (both eclipse and intellij) >>> are >>>totally messed up -- maven 3 messes up the classpath because it can't >>> deal >>>with the variables. So, I'm stuck on maven 2. >>> >>>Now, I don't see this as providing the slightest obstacle to my ability >>> to >>>get repeatable builds. Rather, it's the opposite -- if I want to repeat >>> a >>>build all I have to know is the subversion revision number of the build >>> I >>>want and I can check out that revision and rebuild to recreate an exact >>> copy >>>of the original. >>> >>>Just because maven thinks that an alternative approach is 'convention' >>>doesn't mean that I shouldn't be able to achieve this. CoC is supposed >>> to >>>allow one the choice of following convention, but provide the ability to >>> use >>>configuration where the convention does not fit one's requirements. >>> >>>So, what to do? >>> >>>Bryan > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
