Hi Gary, I forgot to ask: I ended up copying the test data files and test class files (in src/test/resources/test-data and src/test/java/code/) from the core to commons-vfs-jackrabbit3. Is there a good way to avoid duplicates?
I didn't choose Maven dependency plugin's unpack as it requires 'package' executed first. Maven resource plugin can copy from the core directory, but copying he test resources with no possibility of filtering -- even if not used at the moment -- makes me hesitate. Regards, Woonsan On Thu, Mar 7, 2019 at 12:46 AM Woonsan Ko <woon...@apache.org> wrote: > > 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
