Agreed. And keep some pressure on the svn community to fix the issue. I think it has gone under the svn radar for a while because of workarounds like this. I have not interfaced with the svn community myself so I am not practicing what I am preaching ;-).
--- Todd Thiessen > -----Original Message----- > From: Brian E. Fox [mailto:[email protected]] > Sent: Wednesday, April 01, 2009 10:22 AM > To: Maven Users List > Subject: RE: [ANN] Maven Release Plugin 2.0-beta-9 Released > > 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:[email protected]] > 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: [email protected] [mailto:[email protected]] > 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 <[email protected]>: > > > (taking this back to the users list) > > > > > > On Wed, Apr 1, 2009 at 10:01 AM, Olivier Lamy > > <[email protected]> wrote: > > >> 2009/4/1 Jorg Heymans <[email protected]>: > > >>> On Wed, Apr 1, 2009 at 9:33 AM, Olivier Lamy > > <[email protected]> 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: [email protected] > > > For additional commands, e-mail: [email protected] > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
