This has been discussed for the release plugin. The thing is, someone has to implement it. Maybe this "someone" is you?
Btw, sorry for the previous empty mail. I blame my phone... /Anders (mobile) Den 2 jun 2011 00.23 skrev "Russ Tremain" <[email protected]>: > At 9:26 PM +0200 5/29/11, Arnaud Héritier wrote: >>For now it is just impossible to use properties in GAV for various technical >>and also philosophical reasons. > > > I still don't see why the maven deployment plugin cannot be responsible for hardening artifact properties inside deployed poms. > The help plugin goal help:effective-pom does this for example. > > This would effectively synchronize the external location of the artifact with the contents of the artifact's pom. > > /r > > >>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] >>> >>> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] >
