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]
