You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Woonsan Ko <wo...@apache.org> on 2019/03/07 05:46:28 UTC
Re: [vfs] webdav4 extending http4 provider?
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 <wo...@apache.org> wrote:
>
> On Mon, Feb 25, 2019 at 9:28 AM Gary Gregory <ga...@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 <wo...@apache.org> wrote:
> >
> > > On Mon, Feb 25, 2019 at 8:07 AM Gary Gregory <ga...@gmail.com>
> > > wrote:
> > > >
> > > > On Sun, Feb 24, 2019 at 4:00 PM Woonsan Ko <wo...@apache.org> wrote:
> > > >
> > > > > On Mon, Feb 18, 2019 at 2:09 PM Woonsan Ko <wo...@apache.org> wrote:
> > > > > >
> > > > > > On Mon, Feb 18, 2019 at 1:45 PM Gary Gregory <garydgregory@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 <woonsan@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-unsubscribe@commons.apache.org
> > > > > > > > For additional commands, e-mail: dev-help@commons.apache.org
> > > > > > > >
> > > > > > > >
> > > > >
> > > > > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > > > For additional commands, e-mail: dev-help@commons.apache.org
> > > > >
> > > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > For additional commands, e-mail: dev-help@commons.apache.org
> > >
> > >
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [vfs] webdav4 extending http4 provider?
Posted by Woonsan Ko <wo...@apache.org>.
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 <wo...@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 <wo...@apache.org> wrote:
> >
> > On Mon, Feb 25, 2019 at 9:28 AM Gary Gregory <ga...@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 <wo...@apache.org> wrote:
> > >
> > > > On Mon, Feb 25, 2019 at 8:07 AM Gary Gregory <ga...@gmail.com>
> > > > wrote:
> > > > >
> > > > > On Sun, Feb 24, 2019 at 4:00 PM Woonsan Ko <wo...@apache.org> wrote:
> > > > >
> > > > > > On Mon, Feb 18, 2019 at 2:09 PM Woonsan Ko <wo...@apache.org> wrote:
> > > > > > >
> > > > > > > On Mon, Feb 18, 2019 at 1:45 PM Gary Gregory <garydgregory@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 <woonsan@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-unsubscribe@commons.apache.org
> > > > > > > > > For additional commands, e-mail: dev-help@commons.apache.org
> > > > > > > > >
> > > > > > > > >
> > > > > >
> > > > > > ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > > > > For additional commands, e-mail: dev-help@commons.apache.org
> > > > > >
> > > > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > > For additional commands, e-mail: dev-help@commons.apache.org
> > > >
> > > >
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org