commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Struberg <>
Subject AW: [releasing] SVN Tag creeated by maven
Date Wed, 13 May 2009 19:06:51 GMT

> So if you tag the RC as DBUTILS_1_2_RC1 then the 
> source code includes "RC1".  If you then later copy that tag to "DBUTILS_1_2" 
> the source code will still say "RC1".

Sorry Dan, there are a lot things missing in mavens release process, but this very thing is
imho not a problem with maven but with the weirdness of SVN handling tags. If you make a svn:copy,
then you _will_ create_a_new_tag_! So pom.xml still contains exactly that what has been released,
and not only pom.xml, but _ALL_ release artifacts e.g. the sources.tar.gz, etc. Renaming tags,
moving tags etc is essentially a no-no if you don't perform a build from that exact location
afterwards. SVN guaranties atomic operations - at least _almost_ always. And I've seen a lot
of weirdness in my last 20 years of using SCMs where this 'almost' did matter a lot ;) If
you have to make sure 100%, then you have to build from the exact location.

What's wrong with the maven-staging? You tag as if you do a release (with exact that tag in
SVN and pom.xml) but the results will not be deployed to the final repo but only to a staging
repo. Maybe I only missed that part of the discussion, sorry for the noise then.


----- Urspr√ľngliche Mail ----
> Von: Dan Fabulich <>
> An: Commons Developers List <>
> Gesendet: Mittwoch, den 13. Mai 2009, 20:47:34 Uhr
> Betreff: Re: [releasing] SVN Tag creeated by maven
> sebb wrote:
> > However, if the directory names within the archives contain the -RC2
> > suffix, then that is a different matter. Maybe a Maven expert can give
> > advice here on how to work with immutable tags?
> I consider myself reasonably expert with Maven, and my opinion is that Maven's 
> release process is entirely wrong and does not embody a best practice.  :-(
> The problem here is that the source code (the pom.xml file) contains the path to 
> the source code in subversion.  So if you tag the RC as DBUTILS_1_2_RC1 then the 
> source code includes "RC1".  If you then later copy that tag to "DBUTILS_1_2" 
> the source code will still say "RC1".
> Since you can't modify the source code after the vote, your best bet is to 
> create the RC with the final location for the tag and delete/re-tag for each RC. 
> :-(
> IMO, it's entirely wrong for the pom.xml source code to describe the location of 
> the source code.  The reason Maven wants this information there is so when it 
> goes to deploy (either for snapshots or releases) the deployed .pom file in the 
> Maven repository will contain a link to the source code.
> That feature should be implemented by inserting the source link in the deployed 
> .pom file at deploy time.  (It should be auto-detected, or read from some 
> non-checked-in location or manually specified at that time.)
> At a more philosophical level, the only reason Maven *has* a release plugin is 
> because its release philosophy is wrong: the Maven philosophy is to make changes 
> to the source code at release time, which is fundamentally a bad idea which I 
> hope we can fix some day.
> -Dan
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message