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/06/02 00:23:07 UTC
Re: Maven 3.0 Artefact/Dependency version discussion request
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 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
>