Hi Gary, I've created a pull request: https://github.com/apache/commons-vfs/pull/52 But it's just for early-review purpose, not ready for merging yet, mainly because it depends on Jackrabbit 2.19.2-SNAPSHOT at the moment. I'll merge my PR [1] to Jackrabbit myself, and I will need to wait for cutting a release. While waiting, I'll work on these: (a) Java 9 JPMS rules, (b) move the old, webdav provider to a new module, commons-vfs2-jackrabbit2, and (c) add webdav4s provider based on http4s.
Regards, Woonsan [1] https://github.com/apache/jackrabbit/pull/82 On Mon, Feb 25, 2019 at 10:32 AM Woonsan Ko <woon...@apache.org> wrote: > > On Mon, Feb 25, 2019 at 9:28 AM Gary Gregory <garydgreg...@gmail.com> wrote: > > > > Stepping back, It seems to me we have two paths: > > - Update Jackrabbit transparently and open ourselves up to _potential_ > > compatibility issues. > > - Do it the way we did for HttpCore 3 to 4 (which is what we are talking > > about here.) > > > > What about this: > > - Instead of adding code to the sandbox, create a new module > > commons-vfs2-jackrabbitt3 (note the 3) and put your new code in there > > making sure it plays by the Java 9 JPMS rules (or not, up to you). > > - Optionally and preferably, move the current code to a new module > > commons-vfs2-jackrabbitt2 (note the 2) > > All sound good to me! I will add commons-vfs2-jackrabbit3 and > commons-vfs2-jackrabbit2 like described above. > > BTW, Jackrabbit v3 also means OAK [1], the new content repository > under Jackrabbit umbrella, but I think it's totally fine to call it > jackrabbit3 for the provider module because OAK also uses Jackrabbit > v2's API, WebDAV modules, etc, anyway. e.g, OAK 1.10 works with > Jackrabbit 2.18 WebDAV module as OAK itself doesn't provide WebDAV > feature. > > [1] https://jackrabbit.apache.org/oak/docs/dev_getting_started.html > > > > > I am hoping this can all be done in the VFS2 framework. > > Indeed. That's a lot better. > > > > > This will get us started on the path of having module with required > > dependencies instead of one core module with a ton of optional dependencies. > > +1 > > > > > Thoughts? Flying tomatoes? > > Thank you so much for your insightful guidance. > > Cheers, > > Woonsan > > > > > Gary > > > > On Mon, Feb 25, 2019 at 9:06 AM Woonsan Ko <woon...@apache.org> wrote: > > > > > 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 > > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org