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
