Mailing-List: contact users-help@maven.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Maven Users List" <users@maven.apache.org>
Received-SPF: pass (athena.apache.org: domain of russt@releasetools.org
 designates 67.222.39.55 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default;
 d=releasetools.org;
	h=Received:Mime-Version:Message-Id:In-Reply-To:References:Date:To:From:Subject:Cc:Content-Type:Content-Transfer-Encoding:X-Identified-User;
	b=SxvbEHn6GQRj8LYVPOPWLRtKUhAso58a5OOk2fCbLffSwMlElB71Cvx9iTz+b/CaTOacaMJdTECtadmDQ62SKbNY47hAIX/wU+UOf6FUE/UK5QmJ956Qx+rdrkAYRcsk;
Mime-Version: 1.0
Message-Id: <p06240802ca0c692d9eef@[10.1.125.126]>
In-Reply-To: <BANLkTi=YamUpfzfsa0bteXmaWtPfH4aveg@mail.gmail.com>
References: <1E67D6D2-3053-4BD2-A653-89AFC75E67B3@maven.org>
 <562346791003120521v4722ed58x2fe606df58e741a8@mail.gmail.com>
 <31AA3265EBDE914CB013E2EA261EEF6E4078D7@smbfiscbd01.FNFIS.COM>
 <562346791003120656v5c4238a2vbca68b79632c1711@mail.gmail.com>
 <1301142100158-4265445.post@n5.nabble.com>
 <p06240802c9f86a009fe2@10.1.125.126>
 <BANLkTi=VXuT1b_YVY6B4oaHSZ+N3d8oa0w@mail.gmail.com>
 <ac19843ff8f87125a1b14b058812098a.squirrel@www.mosabuam.com>
 <BANLkTi=YamUpfzfsa0bteXmaWtPfH4aveg@mail.gmail.com>
Date: Wed, 1 Jun 2011 15:23:07 -0700
To: "Maven Users List" <users@maven.apache.org>
From: Russ Tremain <russt@releasetools.org>
Subject: Re: Maven 3.0 Artefact/Dependency version discussion request
Cc: Maven Users List <users@maven.apache.org>, manfred@mosabuam.com
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

At 9:26 PM +0200 5/29/11, Arnaud H=E9ritier wrote:
>For now it is just impossible to use properties in GAV for various technica=
l
>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 <manfred@mosabuam.com> 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 <russt@releasetools.org>
>> > 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=3D$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 intelli=
j)
>> >>> 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 abilit=
y
>> >>> to
>> >>>get repeatable builds. Rather, it's the opposite -- if I want to repea=
t
>> >>> a
> > >>>build all I have to know is the subversion revision number of the bui=
ld
>> >>> I
>> >>>want and I can check out that revision and rebuild to recreate an exac=
t
>> >>> 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: users-unsubscribe@maven.apache.org
>> > For additional commands, e-mail: users-help@maven.apache.org
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org