maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Russ Tremain <ru...@releasetools.org>
Subject Re: Maven 3.0 Artefact/Dependency version discussion request
Date Wed, 01 Jun 2011 22:23:07 GMT
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 <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=$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


Mime
View raw message