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.

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 <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
>
>

Reply via email to