For now it is just impossible to use properties in GAV for various technical and also philosophical reasons. You may not be agree with the philosophy behind this choice but it is sure that for now it is more secure in Maven to avoid this usage as it creates many issues.
About the philosophy even if I can be agree that having in the project version the one of the SCM may be useful it is with really few SCMs. For exemple with CVS it is impossible as each file has a different version. And For a DSCM like Git & co your version will be a hash and thus you won't be able to sort them. Arnaud On Thu, May 26, 2011 at 5:24 PM, Manfred Moser <[email protected]> wrote: > 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] > >
