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) I am hoping this can all be done in the VFS2 framework. 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. Thoughts? Flying tomatoes? 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 > >
