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]
