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/02/18 18:19:11 UTC
[vfs] webdav4 extending http4 provider?
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
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
Re: [vfs] webdav4 extending http4 provider?
Posted by Woonsan Ko <wo...@apache.org>.
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>.
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 Gary Gregory <ga...@gmail.com>.
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 <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
>
>
Re: [vfs] webdav4 extending http4 provider?
Posted by Woonsan Ko <wo...@apache.org>.
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 <ga...@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
Re: [vfs] webdav4 extending http4 provider?
Posted by Gary Gregory <ga...@gmail.com>.
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 <ga...@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.
What we should talk about is whether we should make each provider its own
Maven module.
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
>
>
Re: [vfs] webdav4 extending http4 provider?
Posted by Woonsan Ko <wo...@apache.org>.
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 <ga...@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?
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
Re: [vfs] webdav4 extending http4 provider?
Posted by Woonsan Ko <wo...@apache.org>.
On Mon, Feb 18, 2019 at 1:45 PM Gary Gregory <ga...@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?
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
Re: [vfs] webdav4 extending http4 provider?
Posted by Gary Gregory <ga...@gmail.com>.
Hi Woonsan,
Why disable existing tests?
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
>
>