You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Russ Tremain <ru...@releasetools.org> on 2011/05/17 20:12:05 UTC
Re: Maven 3.0 Artefact/Dependency version discussion request
+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
>
>
>--
>View this message in context: http://maven.40175.n5.nabble.com/Re-Maven-3-0-Artefact-Dependency-version-discussion-request-tp83857p4265445.html
>Sent from the Maven - Users mailing list archive at Nabble.com.
>
>---------------------------------------------------------------------
>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
Re: Maven 3.0 Artefact/Dependency version discussion request
Posted by Anders Hammar <an...@hammar.net>.
/Anders (mobile)
Den 2 jun 2011 00.23 skrev "Russ Tremain" <ru...@releasetools.org>:
> 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 <ma...@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=$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: 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
>
Re: Maven 3.0 Artefact/Dependency version discussion request
Posted by Anders Hammar <an...@hammar.net>.
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" <ru...@releasetools.org>:
> 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 <ma...@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=$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: 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
>
Re: Maven 3.0 Artefact/Dependency version discussion request
Posted by Russ Tremain <ru...@releasetools.org>.
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 <ma...@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 <ru...@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=$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: 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
Re: Maven 3.0 Artefact/Dependency version discussion request
Posted by Arnaud Héritier <ah...@gmail.com>.
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 <ma...@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 <ru...@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=$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: 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
>
>
Re: Maven 3.0 Artefact/Dependency version discussion request
Posted by Manfred Moser <ma...@mosabuam.com>.
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 <ru...@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=$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: 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
Re: Maven 3.0 Artefact/Dependency version discussion request
Posted by Zac Thompson <za...@gmail.com>.
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 <ru...@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=$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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org