I agree completely, but until/unless the svn team fixes this major defect, there's not much we can do. (besides switch everyone to git ;-) )
-----Original Message----- From: Todd Thiessen [mailto:thies...@nortel.com] Sent: Wednesday, April 01, 2009 10:18 AM To: Maven Users List Subject: RE: [ANN] Maven Release Plugin 2.0-beta-9 Released I was pleased when I heard that there was a fix for the tags not working with svn in 1.5.1 bug [1]. I didn't look into the solution in great detail at first and I apologize for that. It is little difficult to look at everything all the time as I am sure you all are familiar with. I did take a little time this morning to understand the solution however. I never did understand what "remoteTagging" meant for an option in the release plugin (which needs to be documented, btw, on the release plugin site). So if I understand remote tagging correctly, this means that a tag is taken off the trunk, not the working copy. Doesn't this break backwards compatibility? For instance if there are users out there who do rely on making a tag of the working copy to ensure that you don't tag something committed during a build, once they upgrade to release 9 of the release plugin, this won't work for them anymore. I view the remoteTaggins option as a work around. It is fundamentally a bug in svn (it did work in pre 1.5.1, and doing an svn copy of a working copy is documented to work [2]). If svn ever fixes it, then the remoteTagging option wouldn't be needed anymore and should be defaulted to false. I understand the comments in [3] which indicate that the likelihood of a commit occurring during a build isn't the common case, but how can you tell? This could happen more than we might think and there are tags of releases out there which do not match the built artifacts. There is no way to know without doing a detailed analysis of the artifacts and the tagged source. I feel it is pretty safe to say that such an analysis hasn't been done ;-). Even if someone did happen to stumble upon such a case where they were stepping through the source in there debugger and noticed that lines didn't match up. It may be dismissed if the lines were "close enough" to follow or simply upgrading to a more recent version of the artifact all of a sudden fixes it. Ultimately I feel we still need an svn solution to this. Remote tagging is only a work around. My 2 cents anyway. [1] http://jira.codehaus.org/browse/SCM-406 [2] http://svnbook.red-bean.com/en/1.0/re07.html [3] http://jira.codehaus.org/browse/SCM-262 --- Todd Thiessen > -----Original Message----- > From: oliver.l...@gmail.com [mailto:oliver.l...@gmail.com] On > Behalf Of Olivier Lamy > Sent: Wednesday, April 01, 2009 6:54 AM > To: Maven Users List > Subject: Re: [ANN] Maven Release Plugin 2.0-beta-9 Released > > 2009/4/1 Jorg Heymans <jorg.heym...@gmail.com>: > > (taking this back to the users list) > > > > On Wed, Apr 1, 2009 at 10:01 AM, Olivier Lamy > <ol...@apache.org> wrote: > >> 2009/4/1 Jorg Heymans <jorg.heym...@gmail.com>: > >>> On Wed, Apr 1, 2009 at 9:33 AM, Olivier Lamy > <ol...@apache.org> wrote: > >>> > >>>> Try mvn help:effective-pom I'm not sure the scm > information is correct. > >>> > >>> I don't know what to make from the scm info, in any case > it points > >>> to a non-existing tag: > >>> > >>> <scm> > >>> > >>> > <connection>scm:svn:http://server/svn/project/tags/myparent-4/myproj > >>> ect</connection> > >>> > >>> > <developerConnection>scm:svn:http://server/svn/project/tags/myparent > >>> -4/myproject</developerConnection> > >>> </scm> > >>> > >>> The "myproject" at the end seems bad. In any case somehow > beta-8 was > >>> able to cope with this, wierd. > >> > >> :-) (in this case IMHO your project is bad : publishing site will > >> publish bad source info etc.. changelog plugin can not work etc..) > > > > The released parent pom contains this scm element : > > > > <scm> > > > > > <connection>scm:svn:http://server/svn/project/tags/myparent-4</connect > > ion> > > > > > <developerConnection>scm:svn:http://server/svn/project/tags/myparent-4 > > </developerConnection> > > </scm> > > > > Do you mean this is wrong ? > No the release parent has correct information but not your child(s) > pom(s) because if the child doesn't have any scm information > they are inherited from the parent ! + your current project's > artifactId > > in your case effective pom will be : > <scm> > > <connection>scm:svn:http://server/svn/project/tags/myparent-4/ > ${artifactId}</connection> > > <developerConnection>scm:svn:http://server/svn/project/tags/my > parent-4/${artifactId}</developerConnection> > </scm> > > And IMHO this is not correct for your current project ! > SIte informations won't be correct. > Your child poms must contains their own scm informations > (something like) : > > <scm> > > <connection>scm:svn:http://server/svn/project/myparent/trunk/$ {artifactId}</connection> > > <developerConnection>scm:svn:http://server/svn/project/myparen > t/trunk/${artifactId}</developerConnection> > </scm> > > Sure it's a side effect of using remote tagging to have a > workaround on the svn > 1.5.0 issue. > But you can set remoteTagging to false in the release plugin > configuration. > > > > Thanks, > > Jorg > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > > For additional commands, e-mail: users-h...@maven.apache.org > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
