Re: webdav wagon changes
On Fri, May 23, 2008 at 12:23 AM, Brett Porter <[EMAIL PROTECTED]> wrote: > > On 23/05/2008, at 12:49 PM, Nathan Beyer wrote: > > >>> You'd need to do that anyway to change the version, right? >>> >>> >> I don't know, would you? I'm using a POM with no reference to a WebDAV >> other >> than use 'dav:' URLs in the deployment section, so the provider is just >> being chosen for me. I assumed that as I upgrade the core maven tool (eg >> 2.0.9 to 2.0.10), updates to the providers would just come along if pulled >> in. >> > > Yes, regardless of what we call it that'll be the case. What webdav wagon > gets incorporated into Maven is a separate discussion. The default provider is what will be most important, so I'm fine with the suggested changes. > > > Before 2.0.9, I was adding this to the build section. >> >> >> >> org.apache.maven.wagon >> wagon-webdav >> >> >> >> Doesn't that just pull in the latest version? >> > > You're right, I think it does. That being the case, we certainly don't want > to auto-upgrade someone to a different implementation IMO. > > >>> This is the discussion to come up with that plan :) >>> >>> Sorry, I hadn't seen your other message before I last posted. But this is >>> what I propose: >>> - rename to webdav-jackrabbit >>> - have no -webdav module in the final release >>> >>> >> The final release of what? The core maven package? >> > > Sorry, I meant in Wagon 1.0 (and any preceding betas). > > > Cheers, > Brett > > -- > Brett Porter > [EMAIL PROTECTED] > http://blogs.exist.com/bporter/ > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: webdav wagon changes
I agree with this sentiment for most plugins, but in this case, using an extension was temporary until webdav was a default provider. Additionally, functionality in this case is close to binary, either the artifacts get uploaded or not, so I was less concerned. -Nathan On Fri, May 23, 2008 at 7:35 AM, Brian Fox <[EMAIL PROTECTED]> wrote: > You really should be declaring the versions you want so it only changes > when you are ready. > > > --Brian > > > On May 22, 2008, at 10:49 PM, "Nathan Beyer" <[EMAIL PROTECTED]> wrote: > > On Thu, May 22, 2008 at 2:26 AM, Brett Porter <[EMAIL PROTECTED]> wrote: >> >> >>> On 22/05/2008, at 12:03 PM, Nathan Beyer wrote: >>> >>> Currently, my organization is utilizing the default provider, so we'll >>> have to add additional bits to all of our POMs to take advantage of the provider that's NOT of the EOL path. The default provider for WebDAV is on EOL, correct? Will the jackrabbit provider eventually become the default provider? >>> You'd need to do that anyway to change the version, right? >>> >>> >> I don't know, would you? I'm using a POM with no reference to a WebDAV >> other >> than use 'dav:' URLs in the deployment section, so the provider is just >> being chosen for me. I assumed that as I upgrade the core maven tool (eg >> 2.0.9 to 2.0.10), updates to the providers would just come along if pulled >> in. Before 2.0.9, I was adding this to the build section. >> >> >> >> org.apache.maven.wagon >> wagon-webdav >> >> >> >> Doesn't that just pull in the latest version? >> >> >> >>> >>> >>> I'd be more amenable to Jason's thinking if there was at least a loose plan for what's going to happen, but frankly I'm still skeptical. >>> This is the discussion to come up with that plan :) >>> >>> Sorry, I hadn't seen your other message before I last posted. But this is >>> what I propose: >>> - rename to webdav-jackrabbit >>> - have no -webdav module in the final release >>> >>> >> The final release of what? The core maven package? >> >> >> >>> - make sure wagon-webdav 1.0-beta-2 works with the new API, but >>> discourage >>> it's use >>> >>> WDYT? >>> >>> The wagon >>> development/community is so isolated, non-responsive and slow I'm skeptical of anything going on here. Does wagon development discussion only happen on IRC? >>> There wasn't anything going on here. That's why I'm currently going >>> through >>> all the issues, and posting to the list with anything controversial. >>> >>> I hope that if we have a 1.0 release, and JIRA is not full of old issues >>> that you can't see the forest for the trees, it'll be easier to respond >>> to >>> patches and such as they arrive. Thanks for the patches you personally >>> submitted, btw - and sorry we didn't get to them sooner. >>> >>> >>> Cheers, >>> Brett >>> >>> -- >>> Brett Porter >>> [EMAIL PROTECTED] >>> http://blogs.exist.com/bporter/ >>> >>> >>> - >>> 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] > >
Re: webdav wagon changes
You really should be declaring the versions you want so it only changes when you are ready. --Brian On May 22, 2008, at 10:49 PM, "Nathan Beyer" <[EMAIL PROTECTED]> wrote: On Thu, May 22, 2008 at 2:26 AM, Brett Porter <[EMAIL PROTECTED]> wrote: On 22/05/2008, at 12:03 PM, Nathan Beyer wrote: Currently, my organization is utilizing the default provider, so we'll have to add additional bits to all of our POMs to take advantage of the provider that's NOT of the EOL path. The default provider for WebDAV is on EOL, correct? Will the jackrabbit provider eventually become the default provider? You'd need to do that anyway to change the version, right? I don't know, would you? I'm using a POM with no reference to a WebDAV other than use 'dav:' URLs in the deployment section, so the provider is just being chosen for me. I assumed that as I upgrade the core maven tool (eg 2.0.9 to 2.0.10), updates to the providers would just come along if pulled in. Before 2.0.9, I was adding this to the build section. org.apache.maven.wagon wagon-webdav Doesn't that just pull in the latest version? I'd be more amenable to Jason's thinking if there was at least a loose plan for what's going to happen, but frankly I'm still skeptical. This is the discussion to come up with that plan :) Sorry, I hadn't seen your other message before I last posted. But this is what I propose: - rename to webdav-jackrabbit - have no -webdav module in the final release The final release of what? The core maven package? - make sure wagon-webdav 1.0-beta-2 works with the new API, but discourage it's use WDYT? The wagon development/community is so isolated, non-responsive and slow I'm skeptical of anything going on here. Does wagon development discussion only happen on IRC? There wasn't anything going on here. That's why I'm currently going through all the issues, and posting to the list with anything controversial. I hope that if we have a 1.0 release, and JIRA is not full of old issues that you can't see the forest for the trees, it'll be easier to respond to patches and such as they arrive. Thanks for the patches you personally submitted, btw - and sorry we didn't get to them sooner. Cheers, Brett -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - 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]
Re: webdav wagon changes
On 23/05/2008, at 12:49 PM, Nathan Beyer wrote: You'd need to do that anyway to change the version, right? I don't know, would you? I'm using a POM with no reference to a WebDAV other than use 'dav:' URLs in the deployment section, so the provider is just being chosen for me. I assumed that as I upgrade the core maven tool (eg 2.0.9 to 2.0.10), updates to the providers would just come along if pulled in. Yes, regardless of what we call it that'll be the case. What webdav wagon gets incorporated into Maven is a separate discussion. Before 2.0.9, I was adding this to the build section. org.apache.maven.wagon wagon-webdav Doesn't that just pull in the latest version? You're right, I think it does. That being the case, we certainly don't want to auto-upgrade someone to a different implementation IMO. This is the discussion to come up with that plan :) Sorry, I hadn't seen your other message before I last posted. But this is what I propose: - rename to webdav-jackrabbit - have no -webdav module in the final release The final release of what? The core maven package? Sorry, I meant in Wagon 1.0 (and any preceding betas). Cheers, Brett -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: webdav wagon changes
On Thu, May 22, 2008 at 2:26 AM, Brett Porter <[EMAIL PROTECTED]> wrote: > > On 22/05/2008, at 12:03 PM, Nathan Beyer wrote: > > Currently, my organization is utilizing the default provider, so we'll >> have >> to add additional bits to all of our POMs to take advantage of the >> provider >> that's NOT of the EOL path. The default provider for WebDAV is on EOL, >> correct? Will the jackrabbit provider eventually become the default >> provider? >> > > You'd need to do that anyway to change the version, right? > I don't know, would you? I'm using a POM with no reference to a WebDAV other than use 'dav:' URLs in the deployment section, so the provider is just being chosen for me. I assumed that as I upgrade the core maven tool (eg 2.0.9 to 2.0.10), updates to the providers would just come along if pulled in. Before 2.0.9, I was adding this to the build section. org.apache.maven.wagon wagon-webdav Doesn't that just pull in the latest version? > > > >> >> I'd be more amenable to Jason's thinking if there was at least a loose >> plan >> for what's going to happen, but frankly I'm still skeptical. >> > > This is the discussion to come up with that plan :) > > Sorry, I hadn't seen your other message before I last posted. But this is > what I propose: > - rename to webdav-jackrabbit > - have no -webdav module in the final release > The final release of what? The core maven package? > > - make sure wagon-webdav 1.0-beta-2 works with the new API, but discourage > it's use > > WDYT? > > The wagon >> development/community is so isolated, non-responsive and slow I'm >> skeptical >> of anything going on here. Does wagon development discussion only happen >> on >> IRC? >> > > There wasn't anything going on here. That's why I'm currently going through > all the issues, and posting to the list with anything controversial. > > I hope that if we have a 1.0 release, and JIRA is not full of old issues > that you can't see the forest for the trees, it'll be easier to respond to > patches and such as they arrive. Thanks for the patches you personally > submitted, btw - and sorry we didn't get to them sooner. > > > Cheers, > Brett > > -- > Brett Porter > [EMAIL PROTECTED] > http://blogs.exist.com/bporter/ > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: webdav wagon changes
On 22/05/2008, at 12:03 PM, Nathan Beyer wrote: Currently, my organization is utilizing the default provider, so we'll have to add additional bits to all of our POMs to take advantage of the provider that's NOT of the EOL path. The default provider for WebDAV is on EOL, correct? Will the jackrabbit provider eventually become the default provider? You'd need to do that anyway to change the version, right? I'd be more amenable to Jason's thinking if there was at least a loose plan for what's going to happen, but frankly I'm still skeptical. This is the discussion to come up with that plan :) Sorry, I hadn't seen your other message before I last posted. But this is what I propose: - rename to webdav-jackrabbit - have no -webdav module in the final release - make sure wagon-webdav 1.0-beta-2 works with the new API, but discourage it's use WDYT? The wagon development/community is so isolated, non-responsive and slow I'm skeptical of anything going on here. Does wagon development discussion only happen on IRC? There wasn't anything going on here. That's why I'm currently going through all the issues, and posting to the list with anything controversial. I hope that if we have a 1.0 release, and JIRA is not full of old issues that you can't see the forest for the trees, it'll be easier to respond to patches and such as they arrive. Thanks for the patches you personally submitted, btw - and sorry we didn't get to them sooner. Cheers, Brett -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: webdav wagon changes
WebDAV users are already using a crappy beta provider, will this really be any worse? Currently, my organization is utilizing the default provider, so we'll have to add additional bits to all of our POMs to take advantage of the provider that's NOT of the EOL path. The default provider for WebDAV is on EOL, correct? Will the jackrabbit provider eventually become the default provider? I'd be more amenable to Jason's thinking if there was at least a loose plan for what's going to happen, but frankly I'm still skeptical. The wagon development/community is so isolated, non-responsive and slow I'm skeptical of anything going on here. Does wagon development discussion only happen on IRC? -Nathan On Wed, May 21, 2008 at 10:01 AM, Jason van Zyl <[EMAIL PROTECTED]> wrote: > > On 20-May-08, at 9:17 AM, Brian E. Fox wrote: > > I agree a single provider is less confusing. What if jackrabbit is the >> trunk and we make slide a branch? If the api hasn't changed, then it should >> be ok. >> >> > It's not the API that matters, that has to be the same. It's the way it > behaves. You lose nothing have two providers and not changing the way > everyone uses it now while having the option to use something new. You have > no idea what the behavior may, or may not, push on to users of WebDAV. Just > avoid the potential problem of calling it the same thing, finding out there > is a problem, trying to roll it back, and by some weirdism in maven-artifact > users get the wrong provider. Don't make it more complicated then it has to > be. People can choose the new implementation when they want. > > We have enough problems with users complaining about the auto-magical > update. Do we really want to explain "Oh we called it the same thing but we > completely changed the implementation while it was in beta." > > > -Original Message- >> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nathan >> Beyer >> Sent: Tuesday, May 20, 2008 10:26 AM >> To: wagon-dev@maven.apache.org >> Subject: Re: webdav wagon changes >> >> I'd prefer a single 'webdav' provider. If there are concerns of passivity >> or >> correctness, then I'd suggest a call out for help testing it, which could >> identify any possible regressions. The slide-impl is pretty bad and I'd be >> willing to live and work through any bumps for a long-term win. >> >> If there's a SNAPSHOT or a way of building one and some quick instructions >> on how to replace the slide impl in 2.0.9, I'd certainly be able to start >> some larger-scale integration testing. >> >> -Nathan >> >> On Tue, May 20, 2008 at 12:43 AM, Brett Porter <[EMAIL PROTECTED]> wrote: >> >> Hi, >>> >>> I just finished some work to migrate the webdav provider from slide to >>> jackrabbit using the patch from James Dumay. Slide leaked some file >>> handles >>> and is an unsupported project. In the process I added some more tests >>> around >>> transfer listeners as some providers weren't registering them correctly. >>> >>> Jason suggested on IRC that it might be better to retain the slide webdav >>> provider as-is and move the new code to wagon-webdav-jackrabbit. >>> >>> Any opinions on this before I go ahead and do that? >>> >>> I'm thinking of still renaming the slide wagon to wagon-webdav-slide in >>> such a case, so that on upgrading the version they are forced to choose, >>> but >>> still have access to the slide one if needed. >>> >>> The only issue I can see is it clashing with the other one built in to >>> 2.0.9 for the plexus 'dav' component, but I haven't tried to see if it >>> wins >>> out correctly if used. >>> >>> BTW, I've also brought the SCM provider in to trunk from the sandbox - >>> it's >>> apparent from JIRA that a number of people are using it, so I think we >>> should support it for the limited use cases it currently supports. >>> >>> Cheers, >>> Brett >>> >>> -- >>> Brett Porter >>> [EMAIL PROTECTED] >>> http://blogs.exist.com/bporter/ >>> >>> >>> - >>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> >>> > Thanks, > > Jason > > -- > Jason van Zyl > Founder, Apache Maven > jason at sonatype dot com > -- > > Selfish deeds are the shortest path to self destruction. > > -- The Seven Samuari, Akira Kirosawa > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: webdav wagon changes
In light of this, I think the best thing to do is: - rename to webdav-jackrabbit - have no -webdav module in the final release - make sure wagon-webdav 1.0-beta-2 works with the new API Cheers, Brett On 22/05/2008, at 1:01 AM, Jason van Zyl wrote: On 20-May-08, at 9:17 AM, Brian E. Fox wrote: I agree a single provider is less confusing. What if jackrabbit is the trunk and we make slide a branch? If the api hasn't changed, then it should be ok. It's not the API that matters, that has to be the same. It's the way it behaves. You lose nothing have two providers and not changing the way everyone uses it now while having the option to use something new. You have no idea what the behavior may, or may not, push on to users of WebDAV. Just avoid the potential problem of calling it the same thing, finding out there is a problem, trying to roll it back, and by some weirdism in maven-artifact users get the wrong provider. Don't make it more complicated then it has to be. People can choose the new implementation when they want. We have enough problems with users complaining about the auto- magical update. Do we really want to explain "Oh we called it the same thing but we completely changed the implementation while it was in beta." -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nathan Beyer Sent: Tuesday, May 20, 2008 10:26 AM To: wagon-dev@maven.apache.org Subject: Re: webdav wagon changes I'd prefer a single 'webdav' provider. If there are concerns of passivity or correctness, then I'd suggest a call out for help testing it, which could identify any possible regressions. The slide-impl is pretty bad and I'd be willing to live and work through any bumps for a long-term win. If there's a SNAPSHOT or a way of building one and some quick instructions on how to replace the slide impl in 2.0.9, I'd certainly be able to start some larger-scale integration testing. -Nathan On Tue, May 20, 2008 at 12:43 AM, Brett Porter <[EMAIL PROTECTED]> wrote: Hi, I just finished some work to migrate the webdav provider from slide to jackrabbit using the patch from James Dumay. Slide leaked some file handles and is an unsupported project. In the process I added some more tests around transfer listeners as some providers weren't registering them correctly. Jason suggested on IRC that it might be better to retain the slide webdav provider as-is and move the new code to wagon-webdav-jackrabbit. Any opinions on this before I go ahead and do that? I'm thinking of still renaming the slide wagon to wagon-webdav- slide in such a case, so that on upgrading the version they are forced to choose, but still have access to the slide one if needed. The only issue I can see is it clashing with the other one built in to 2.0.9 for the plexus 'dav' component, but I haven't tried to see if it wins out correctly if used. BTW, I've also brought the SCM provider in to trunk from the sandbox - it's apparent from JIRA that a number of people are using it, so I think we should support it for the limited use cases it currently supports. Cheers, Brett -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- Selfish deeds are the shortest path to self destruction. -- The Seven Samuari, Akira Kirosawa - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: webdav wagon changes
On 20-May-08, at 9:17 AM, Brian E. Fox wrote: I agree a single provider is less confusing. What if jackrabbit is the trunk and we make slide a branch? If the api hasn't changed, then it should be ok. It's not the API that matters, that has to be the same. It's the way it behaves. You lose nothing have two providers and not changing the way everyone uses it now while having the option to use something new. You have no idea what the behavior may, or may not, push on to users of WebDAV. Just avoid the potential problem of calling it the same thing, finding out there is a problem, trying to roll it back, and by some weirdism in maven-artifact users get the wrong provider. Don't make it more complicated then it has to be. People can choose the new implementation when they want. We have enough problems with users complaining about the auto-magical update. Do we really want to explain "Oh we called it the same thing but we completely changed the implementation while it was in beta." -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nathan Beyer Sent: Tuesday, May 20, 2008 10:26 AM To: wagon-dev@maven.apache.org Subject: Re: webdav wagon changes I'd prefer a single 'webdav' provider. If there are concerns of passivity or correctness, then I'd suggest a call out for help testing it, which could identify any possible regressions. The slide-impl is pretty bad and I'd be willing to live and work through any bumps for a long-term win. If there's a SNAPSHOT or a way of building one and some quick instructions on how to replace the slide impl in 2.0.9, I'd certainly be able to start some larger-scale integration testing. -Nathan On Tue, May 20, 2008 at 12:43 AM, Brett Porter <[EMAIL PROTECTED]> wrote: Hi, I just finished some work to migrate the webdav provider from slide to jackrabbit using the patch from James Dumay. Slide leaked some file handles and is an unsupported project. In the process I added some more tests around transfer listeners as some providers weren't registering them correctly. Jason suggested on IRC that it might be better to retain the slide webdav provider as-is and move the new code to wagon-webdav-jackrabbit. Any opinions on this before I go ahead and do that? I'm thinking of still renaming the slide wagon to wagon-webdav- slide in such a case, so that on upgrading the version they are forced to choose, but still have access to the slide one if needed. The only issue I can see is it clashing with the other one built in to 2.0.9 for the plexus 'dav' component, but I haven't tried to see if it wins out correctly if used. BTW, I've also brought the SCM provider in to trunk from the sandbox - it's apparent from JIRA that a number of people are using it, so I think we should support it for the limited use cases it currently supports. Cheers, Brett -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- Selfish deeds are the shortest path to self destruction. -- The Seven Samuari, Akira Kirosawa - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: webdav wagon changes
I agree a single provider is less confusing. What if jackrabbit is the trunk and we make slide a branch? If the api hasn't changed, then it should be ok. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nathan Beyer Sent: Tuesday, May 20, 2008 10:26 AM To: wagon-dev@maven.apache.org Subject: Re: webdav wagon changes I'd prefer a single 'webdav' provider. If there are concerns of passivity or correctness, then I'd suggest a call out for help testing it, which could identify any possible regressions. The slide-impl is pretty bad and I'd be willing to live and work through any bumps for a long-term win. If there's a SNAPSHOT or a way of building one and some quick instructions on how to replace the slide impl in 2.0.9, I'd certainly be able to start some larger-scale integration testing. -Nathan On Tue, May 20, 2008 at 12:43 AM, Brett Porter <[EMAIL PROTECTED]> wrote: > Hi, > > I just finished some work to migrate the webdav provider from slide to > jackrabbit using the patch from James Dumay. Slide leaked some file handles > and is an unsupported project. In the process I added some more tests around > transfer listeners as some providers weren't registering them correctly. > > Jason suggested on IRC that it might be better to retain the slide webdav > provider as-is and move the new code to wagon-webdav-jackrabbit. > > Any opinions on this before I go ahead and do that? > > I'm thinking of still renaming the slide wagon to wagon-webdav-slide in > such a case, so that on upgrading the version they are forced to choose, but > still have access to the slide one if needed. > > The only issue I can see is it clashing with the other one built in to > 2.0.9 for the plexus 'dav' component, but I haven't tried to see if it wins > out correctly if used. > > BTW, I've also brought the SCM provider in to trunk from the sandbox - it's > apparent from JIRA that a number of people are using it, so I think we > should support it for the limited use cases it currently supports. > > Cheers, > Brett > > -- > Brett Porter > [EMAIL PROTECTED] > http://blogs.exist.com/bporter/ > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: webdav wagon changes
On 21/05/2008, at 12:25 AM, Nathan Beyer wrote: If there's a SNAPSHOT or a way of building one and some quick instructions on how to replace the slide impl in 2.0.9, I'd certainly be able to start some larger-scale integration testing. Thanks - that'd certainly be helpful regardless. You can build from here: http://svn.apache.org/repos/asf/maven/components/branches/maven-2.0.x-jackrabbit-webdav/ -Nathan On Tue, May 20, 2008 at 12:43 AM, Brett Porter <[EMAIL PROTECTED]> wrote: Hi, I just finished some work to migrate the webdav provider from slide to jackrabbit using the patch from James Dumay. Slide leaked some file handles and is an unsupported project. In the process I added some more tests around transfer listeners as some providers weren't registering them correctly. Jason suggested on IRC that it might be better to retain the slide webdav provider as-is and move the new code to wagon-webdav-jackrabbit. Any opinions on this before I go ahead and do that? I'm thinking of still renaming the slide wagon to wagon-webdav- slide in such a case, so that on upgrading the version they are forced to choose, but still have access to the slide one if needed. The only issue I can see is it clashing with the other one built in to 2.0.9 for the plexus 'dav' component, but I haven't tried to see if it wins out correctly if used. BTW, I've also brought the SCM provider in to trunk from the sandbox - it's apparent from JIRA that a number of people are using it, so I think we should support it for the limited use cases it currently supports. Cheers, Brett -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: webdav wagon changes
I'd prefer a single 'webdav' provider. If there are concerns of passivity or correctness, then I'd suggest a call out for help testing it, which could identify any possible regressions. The slide-impl is pretty bad and I'd be willing to live and work through any bumps for a long-term win. If there's a SNAPSHOT or a way of building one and some quick instructions on how to replace the slide impl in 2.0.9, I'd certainly be able to start some larger-scale integration testing. -Nathan On Tue, May 20, 2008 at 12:43 AM, Brett Porter <[EMAIL PROTECTED]> wrote: > Hi, > > I just finished some work to migrate the webdav provider from slide to > jackrabbit using the patch from James Dumay. Slide leaked some file handles > and is an unsupported project. In the process I added some more tests around > transfer listeners as some providers weren't registering them correctly. > > Jason suggested on IRC that it might be better to retain the slide webdav > provider as-is and move the new code to wagon-webdav-jackrabbit. > > Any opinions on this before I go ahead and do that? > > I'm thinking of still renaming the slide wagon to wagon-webdav-slide in > such a case, so that on upgrading the version they are forced to choose, but > still have access to the slide one if needed. > > The only issue I can see is it clashing with the other one built in to > 2.0.9 for the plexus 'dav' component, but I haven't tried to see if it wins > out correctly if used. > > BTW, I've also brought the SCM provider in to trunk from the sandbox - it's > apparent from JIRA that a number of people are using it, so I think we > should support it for the limited use cases it currently supports. > > Cheers, > Brett > > -- > Brett Porter > [EMAIL PROTECTED] > http://blogs.exist.com/bporter/ > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: webdav wagon changes
I think leaving the current impl on slide with the current name is the way to go to maintain backwards compat for 2.0.x. Changing to a new provider may have unforeseen side-effects and for people that aren't having issues now, it should continue to work. On 5/20/08 1:43 AM, "Brett Porter" <[EMAIL PROTECTED]> wrote: > Hi, > > I just finished some work to migrate the webdav provider from slide to > jackrabbit using the patch from James Dumay. Slide leaked some file > handles and is an unsupported project. In the process I added some > more tests around transfer listeners as some providers weren't > registering them correctly. > > Jason suggested on IRC that it might be better to retain the slide > webdav provider as-is and move the new code to wagon-webdav-jackrabbit. > > Any opinions on this before I go ahead and do that? > > I'm thinking of still renaming the slide wagon to wagon-webdav-slide > in such a case, so that on upgrading the version they are forced to > choose, but still have access to the slide one if needed. > > The only issue I can see is it clashing with the other one built in to > 2.0.9 for the plexus 'dav' component, but I haven't tried to see if it > wins out correctly if used. > > BTW, I've also brought the SCM provider in to trunk from the sandbox - > it's apparent from JIRA that a number of people are using it, so I > think we should support it for the limited use cases it currently > supports. > > Cheers, > Brett > > -- > Brett Porter > [EMAIL PROTECTED] > http://blogs.exist.com/bporter/ > > > - > 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]
