Re: Possible bug in Subversion SCM or release plugin
On Wed, Oct 20, 2010 at 11:16 AM, Justin Edelson wrote: > On Oct 20, 2010, at 12:57 PM, Phillip Hellewell wrote: >> >> So how about a solution where you still have to tell it the SCM just >> not the URL, e.g., if the could be set to like >> "scm:svn:infer". > > This would make project materialization from a pom impossible. Stephen's > addition to the scm plugin makes far more sense. Stephen - Rick Mangi has > access to an svn implementation of this and I have a git implementation. Let > me know if you want these (I'll have to ask Rick nicely for the svn one). But what if I don't care about being able to materialize a project from a pom? Anyone not using the scm or release plugins doesn't have a in their poms, so why should I have to have one if I don't need "materialization from a pom"? Now don't get me wrong. I actually do want to be able to materialize a project from a pom. I think that is cool and I really do want it. But due to our layout in SVN I already know just from the artifactId and version exactly where the tag I need is at. So I really don't need a connection setting in the pom to be able to materialize a project from it. Having said all that, I'm not opposed at all to the release pluign adding a section to the pom in the tag that gets created and to the pom that is deployed. It's just on the trunk (and branches) that it would be nice to never have have that defined in there and have to make sure it stays in sync and no one screws it up. Phillip - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Possible bug in Subversion SCM or release plugin
On Oct 20, 2010, at 12:57 PM, Phillip Hellewell wrote: > On Wed, Oct 20, 2010 at 12:29 AM, Stephen Connolly > wrote: >> On 19 October 2010 23:43, Phillip Hellewell wrote: >>> >>> Also, what about my idea that the release plugin ought to just use the >>> working copy URL when an scm connection is not defined? Seems like >>> that would really simplify things, and I don't see any downsides. >>> >> >> the world does not revolve around svn...we'd have to check _LL_ providers > > I see what you mean; asking it to infer not only the URL but also the > SCM you're using is probably asking too much. > > So how about a solution where you still have to tell it the SCM just > not the URL, e.g., if the could be set to like > "scm:svn:infer". This would make project materialization from a pom impossible. Stephen's addition to the scm plugin makes far more sense. Stephen - Rick Mangi has access to an svn implementation of this and I have a git implementation. Let me know if you want these (I'll have to ask Rick nicely for the svn one). Justin > > FYI, on another thread Stephen brought up possibly working on some > type of infer functionality. > > Phillip > > - > 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
Re: Possible bug in Subversion SCM or release plugin
On Tue, Oct 19, 2010 at 4:43 PM, Phillip Hellewell wrote: > > But anyway, should I still submit a bug? I don't know if it is the > release plugin or SCM plugin at fault though... FYI, I created this bug: http://jira.codehaus.org/browse/MRELEASE-609 Phillip - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Possible bug in Subversion SCM or release plugin
On Wed, Oct 20, 2010 at 12:29 AM, Stephen Connolly wrote: > On 19 October 2010 23:43, Phillip Hellewell wrote: >> >> Also, what about my idea that the release plugin ought to just use the >> working copy URL when an scm connection is not defined? Seems like >> that would really simplify things, and I don't see any downsides. >> > > the world does not revolve around svn...we'd have to check _LL_ providers I see what you mean; asking it to infer not only the URL but also the SCM you're using is probably asking too much. So how about a solution where you still have to tell it the SCM just not the URL, e.g., if the could be set to like "scm:svn:infer". FYI, on another thread Stephen brought up possibly working on some type of infer functionality. Phillip - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Possible bug in Subversion SCM or release plugin
On 19 October 2010 23:43, Phillip Hellewell wrote: > Thanks Stephen. See comments below... > > On Tue, Oct 19, 2010 at 4:16 PM, Stephen Connolly > wrote: >> I suspect that this is because you are not using remoteTagging=true >> for your release, so it is trying to create the tag from the working >> copy. > > Ok, but it still shouldn't use the path from the working copy URL with > the protocol from the pom scm connection. > >> the pom is not really designed to handle more than two valid scm >> connection urls (1 is the at least read-only url and the other dev >> connection is at least read-write) > > Unfortunately, half our developers are using http:// and the other > half are using svn+ssh://, and I don't see that changing. > >> when making a release you really should be using the connection >> specified in the devConnection part of the scm section. > > Sounds kinda like an excuse :) How do you handle this scenario in > general? I'm sure many companies out there allow more than one way to > access SVN. So you have to make a rule that only developers who check > out code with a specific protocol can do releases? > >> for svn, setting remote tagging to true should work around your issue >> somewhat. > > Yep, sure enough it that did the trick. Thanks for that workaround! > > But anyway, should I still submit a bug? I don't know if it is the > release plugin or SCM plugin at fault though... > > Also, what about my idea that the release plugin ought to just use the > working copy URL when an scm connection is not defined? Seems like > that would really simplify things, and I don't see any downsides. > the world does not revolve around svn...we'd have to check _LL_ providers > Phillip > > - > 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
Re: Possible bug in Subversion SCM or release plugin
Thanks Stephen. See comments below... On Tue, Oct 19, 2010 at 4:16 PM, Stephen Connolly wrote: > I suspect that this is because you are not using remoteTagging=true > for your release, so it is trying to create the tag from the working > copy. Ok, but it still shouldn't use the path from the working copy URL with the protocol from the pom scm connection. > the pom is not really designed to handle more than two valid scm > connection urls (1 is the at least read-only url and the other dev > connection is at least read-write) Unfortunately, half our developers are using http:// and the other half are using svn+ssh://, and I don't see that changing. > when making a release you really should be using the connection > specified in the devConnection part of the scm section. Sounds kinda like an excuse :) How do you handle this scenario in general? I'm sure many companies out there allow more than one way to access SVN. So you have to make a rule that only developers who check out code with a specific protocol can do releases? > for svn, setting remote tagging to true should work around your issue > somewhat. Yep, sure enough it that did the trick. Thanks for that workaround! But anyway, should I still submit a bug? I don't know if it is the release plugin or SCM plugin at fault though... Also, what about my idea that the release plugin ought to just use the working copy URL when an scm connection is not defined? Seems like that would really simplify things, and I don't see any downsides. Phillip - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Possible bug in Subversion SCM or release plugin
I suspect that this is because you are not using remoteTagging=true for your release, so it is trying to create the tag from the working copy. the pom is not really designed to handle more than two valid scm connection urls (1 is the at least read-only url and the other dev connection is at least read-write) when making a release you really should be using the connection specified in the devConnection part of the scm section. for svn, setting remote tagging to true should work around your issue somewhat. -Stephen On 19 October 2010 23:02, Phillip Hellewell wrote: > Hi all, > > Both of these point to the same place: > My working copy URL: svn+ssh://usern...@addev/svnrep/components/core/trunk > My SCM URL in the pom: scm:svn:http://addev/svn/components/core/trunk > > I'm getting this error when release:prepare tries to create a tag: > svn: Server sent unexpected return value (405 Method Not Allowed) > in response to PROPFIND request for '/svnrep/components/core/trunk' > > It should be using /svn not /svnrep, because it is talking to the HTTP server. > > I sniffed the packets and found that for most of the DAV operations it > is using /svn as it should, but for this one where it goes to create > the tag, it's using /svnrep. It must be grabbing that name from my > local URL, but it shouldn't do that. That path only exists with the > ssh protocol, not when talking to the web server. Maven shouldn't mix > and match parts of the working copy URL with the SCM url. It should > pick one or the other. > > Should I submit a bug for this? > > On a related note, why not have the release plugin just use the > working copy URL if an connection is not defined in the pom? > That would solve all of the following issues for me: > 1. I wouldn't have to define an scm connection in all my poms and make > sure no one ever screws it up. > 2. I wouldn't have to worry about some devs wanting to use http:// and > some want to use svn+ssh://. > 3. I would never run into the bug that this email is about. > > Phillip > > - > 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