maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anders Hammar <and...@hammar.net>
Subject Re: Maven 3.0 Artefact/Dependency version discussion request
Date Thu, 02 Jun 2011 09:09:26 GMT
/Anders (mobile)
Den 2 jun 2011 00.23 skrev "Russ Tremain" <russt@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 <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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message