On Mon, Feb 25, 2019 at 8:07 AM Gary Gregory <garydgreg...@gmail.com> wrote: > > On Sun, Feb 24, 2019 at 4:00 PM Woonsan Ko <woon...@apache.org> wrote: > > > On Mon, Feb 18, 2019 at 2:09 PM Woonsan Ko <woon...@apache.org> wrote: > > > > > > On Mon, Feb 18, 2019 at 1:45 PM Gary Gregory <garydgreg...@gmail.com> > > wrote: > > > > > > > > Hi Woonsan, > > > > > > > > Why disable existing tests? > > > > > > I think the new Jackrabbit dependency 2.19.x would conflict with the > > > old one, 1.6.5. > > > Jackrabbit upgraded httpclient dependency to 4.x since 2.16.0 with no > > > changes in maven coordinates nor package names. > > > If we want to keep the existing tests for the webdav (based on > > > httpclient v3), perhaps we can introduce a new maven submodule (e.g, > > > commons-vfs2-webdav-tests) while keeping only the new tests for > > > webdav4 enabled in the main submodule. Or any better ideas? > > > > Oh, the above wasn't precise enough. > > Jackrabbit 2.16+ also breaks the WebDAV Client code API, so the > > existing webdav package cannot build either. > > For example, org.apache.jackrabbit.webdav.client.methods.DavMethod in > > v1.x is dropped in v2 as it inherits from > > org.apache.commons.httpclient.HttpMethod. > > > > So, an alternative might be to add webdav4 and webdav4s providers in > > commons-vfs2-sandbox subproject instead. The subproject doesn't use > > Jackrabbit dependency. The main submodule won't be touched at all > > regarding this contribution. > > > > Does it sound okay? > > > > It depends on your goal here. The commons-vfs2-sandbox module is not part > of the release, IOW, it does not get released to Maven repositories.
Thanks again for your feedback. Yeah, I knew it was excluded. My main assumption was that VFS2 won't be able to adopt my contribution due to the incompatible API changes from Jackrabbit 2.16+. So, my goal was to contribute a testable, verifiable one in sandbox for now and hope it to replace the old webdav provider in VFS3. That was something I could do now for my final goal: someday allow again WebDAV-based DataStore and FileSystem option in Jackrabbit as well as SFTP-based backend. > > What we should talk about is whether we should make each provider its own > Maven module. I think it is the way to go in the future. Camel also separates each component for different backend. It helps independent dependencies, development and testing. But I guess that would bring "VFS3" branch into the discussions, right? I'd like to help in VFS3 work with separating each provider if it happens. Please chime in if you folks have other thoughts. Kind regards, Woonsan > > Gary > > > > > > Regards, > > > > Woonsan > > > > > > > > Regards, > > > > > > Woonsan > > > > > > > > > > > Gary > > > > > > > > On Mon, Feb 18, 2019, 13:19 Woonsan Ko <woon...@apache.org wrote: > > > > > > > > > Hi, > > > > > > > > > > I'm trying to create a PR as a fix to VFS-686. > > > > > At first, I've tried to fix those in > > > > > org.apache.commons.vfs2.provider.webdav package, but realized that > > the > > > > > changes will break API compatibility. For example, > > > > > WebdavFileSystemConfigBuilder#getInstance() can't be supported as-is > > > > > obviously. > > > > > > > > > > So, I think we should do the following instead: > > > > > - Introduce org.apache.commons.vfs2.provider.webdav4 package like we > > > > > did for http4 FS provider in org.apache.commons.vfs2.provider.http4 > > > > > package. > > > > > - Provide equivalent unit tests for the webdav4 provider, depending > > on > > > > > Jackrabbit 2.19.x+. (Also, see JCR-4401.) > > > > > - Disable the old unit tests for > > > > > org.apache.commons.vfs2.provider.webdav package, which is based on > > > > > http client v3, by default. > > > > > > > > > > How does it sound? > > > > > > > > > > Regards, > > > > > > > > > > Woonsan > > > > > > > > > > --------------------------------------------------------------------- > > > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
