Yep,that can do...
I upgrade vfs to 2.6 and tried adding commons-vfs2-jackrabbit1 and 2 and it
can work correctly now.
thx for your help guys.
Woonsan Ko <woon...@apache.org> 于2020年1月24日周五 上午4:05写道：
> On Thu, Jan 23, 2020 at 2:44 PM Xeno Amess <xenoam...@gmail.com> wrote:
> >
> > Likely but not exactly.
> > the provider I missed im my case here is
> > [org.apache.commons.vfs2.provider.webdav.WebdavFileProvider]
> > and the required classes are [org.apache.commons.httpclient.HttpClient]
> and
> > [org.apache.jackrabbit.webdav.client.methods.DavMethod]
> >
> > I went analyze my pom.
> > I use
> >
> > <dependency>
> > <groupId>org.codehaus.mojo</groupId>
> > <artifactId>versions-maven-plugin</artifactId>
> > <version>2.7</version>
> > </dependency>
> >
> > [versions-maven-plugin] use [maven-plugin-plugin] to generate plugin.xml,
> > and which contains
> >
> > <dependency>
> > <groupId>org.apache.maven.wagon</groupId>
> > <artifactId>wagon-webdav-jackrabbit</artifactId>
> > <type>jar</type>
> > <version>1.0-beta-6</version>
> > </dependency>
> >
> > so [wagon-webdav-jackrabbit] contains
> > [org.apache.jackrabbit.webdav.client.methods.BaseDavRequest]
> >
> > [versions-maven-plugin] use [maven-plugin-plugin] to generate plugin.xml,
> > and which also contains
> >
> > <dependency>
> > <groupId>commons-httpclient</groupId>
> > <artifactId>commons-httpclient</artifactId>
> > <type>jar</type>
> > <version>3.0</version>
> > </dependency>
> >
> > so [commons-httpclient] contains
> [org.apache.commons.httpclient.HttpClient]
> >
> >
> > *So things goes clear here.Every project who have [versions-maven-plugin]
> > 2.7 as dependency will not start VFS normally.*
>
> Thank you very much for your thorough analysis!
> So, the problem may occur when commons-vfs2-jackrabbit1 doesn't exist
> whereas the required classes (if-available elements) exist. A
> temporary workaround could be just to add commons-vfs2-jackrabbit1
> dependency. Of course it's not a real fix.
>
> Back to your PR, I saw you suggest checking the provider class itself
> and skipping if the provider class is unavailable.
> Another approach is to add one more if-available element in the
> providers.xml to make sure whether the _specific_ provider can be
> loaded or not.
> For example, if we added
> 'org.apache.commons.vfs2.provider.webdav.WebdavFileSystem' as a new
> if-available element, it would work too.
> ('org.apache.commons.vfs2.provider.webdav4.Webdav4FileSystem' for
> webdav4 and webdav4s likewise.)
> This approach seems better to me because we can keep the "fail-fast"
> behavior if a provider class is wrong or misconfigured and the fix is
> provider-specific.
>
> Regards,
>
> Woonsan
>
> >
> > versions-maven-plugin is a plugin for auto upgrade version num in pom,
> and
> > is really useful to me.
> > I have no idea about why [versions-maven-plugin]'s author need do this.
> >
> > besides.
> >
> > [versions-maven-plugin]'s plugin.xml contains some things like
> jackrabbit.
> > and yeah there be 3 jackrabbit libs.
> > I have no idea whether they invoke each other or what.
> > I just hope this can be a little useful for you.
> >
> > <dependency>
> > <groupId>org.apache.maven.wagon</groupId>
> > <artifactId>wagon-webdav-jackrabbit</artifactId>
> > <type>jar</type>
> > <version>1.0-beta-6</version>
> > </dependency>
> > <dependency>
> > <groupId>org.apache.jackrabbit</groupId>
> > <artifactId>jackrabbit-webdav</artifactId>
> > <type>jar</type>
> > <version>1.5.0</version>
> > </dependency>
> > <dependency>
> > <groupId>org.apache.jackrabbit</groupId>
> > <artifactId>jackrabbit-jcr-commons</artifactId>
> > <type>jar</type>
> > <version>1.5.0</version>
> > </dependency>
> >
> > besides.
> >
> > I really think split one java package into several maven project be
> > dangerous.
> >
> >
> >
> > Woonsan Ko <woon...@apache.org> 于2020年1月24日周五 上午1:03写道：
> >
> > > On Sun, Jan 19, 2020 at 11:41 AM Xeno Amess <xenoam...@gmail.com>
> wrote:
> > > >
> > > > yep that make sense.
> > > > but I'd rather add a class-check for provider class.
> > > > there already be a mechanism for making sure if all classes needed
> for
> > > > this provider class exist -> if not then just do not add the
> provider.
> > > > I will add a similar mechanism for making sure if the provider class
> > > > itself exist -> if not then just do not add the provider.
> > > > pull request here.
> > > > https://github.com/apache/commons-vfs/pull/78
> > >
> > > I thought the nested if-available elements [1] would do necessary
> > > checks before attempting to create the provider. In my understanding,
> > > if the required class doesn't exist, then the provider won't be
> > > created.
> > > So, in your case, do you have both org.apache.http.client.HttpClient
> > > and org.apache.jackrabbit.webdav.client.methods.BaseDavRequest, but
> > > not have commons-vfs2-jackrabbit1-2.5.0? Is it why you met the
> > > problem?
> > >
> > > Regards,
> > >
> > > Woonsan
> > >
> > > [1]
> > >
> https://github.com/apache/commons-vfs/blob/rel/commons-vfs-2.5.0/commons-vfs2/src/main/resources/org/apache/commons/vfs2/impl/providers.xml#L107-L108
> > >
> > > >
> > > > Rob Spoor <apa...@icemanx.nl> 于2020年1月20日周一 上午12:13写道：
> > > > >
> > > > > It seems that when the webdav support was moved to a separate
> artifact,
> > > > > the developers forgot to update file
> > > > >
> > >
> commons-vfs2/src/main/resources/org/apache/commons/vfs2/impl/providers.xml.
> > > > > This file is used by StandardFileSystemManager to load the default
> > > > > providers.
> > > > >
> > > > > I think this warrants a fix, to move the webdav provider from this
> > > > > default providers.xml file to file
> > > > >
> commons-vfs2-jackrabbit1/src/main/resources/META-INF/vfs-providers.xml,
> > > > > and create the same file with the correct providers for the
> > > > > commons-vfs2-jackrabbit2 module.
> > > > >
> > > > >
> > > > > On 19/01/2020 16:57, Xeno Amess wrote:
> > > > > > OK I get where is bugged.
> > > > > > I will fix it and add a test for that never happen again.
> > > > > >
> > > > > > Xeno Amess <xenoam...@gmail.com> 于2020年1月19日周日 下午11:21写道：
> > > > > >>
> > > > > >> The key point is even if I do not wanna use it I must have this
> > > > > >> class,or VFS.getManager() can never run.
> > > > > >>
> > > > > >> IMO this type of class relationship cause the project where hold
> > > this
> > > > > >> class must be added into vfs's pom as a dependency, or just move
> > > class
> > > > > >> VFS into that project aswell.
> > > > > >>
> > > > > >> Otherwise we should not let the VFS.getManager() rely on this
> class.
> > > > > >>
> > > > > >> Thanks for finding this class though.
> > > > > >>
> > > > > >> btw I tested 2.4, 2.4 is correct.
> > > > > >>
> > > > > >> Rob Spoor <apa...@icemanx.nl> 于2020年1月19日周日 下午10:00写道：
> > > > > >>>
> > > > > >>> The class was there in release 2.4.1:
> > > > > >>>
> > >
> https://github.com/apache/commons-vfs/blob/rel/commons-vfs-2.4.1/commons-vfs2/src/main/java/org/apache/commons/vfs2/provider/webdav/WebdavFileProvider.java
> > > .
> > > > > >>> In the next release, 2.5.0, it can indeed no longer be found. A
> > > bit of
> > > > > >>> investigating showed that the webdav classes got moved to a new
> > > > > >>> artifact:
> > > > > >>>
> > >
> https://github.com/apache/commons-vfs/commit/42ff473acbb5363b88f5ab3c5fddbae7b206c1d2
> > > > > >>>
> > > > > >>> That means you can still use it, you just need to include an
> extra
> > > > > >>> dependency:
> > > > > >>>
> > >
> https://mvnrepository.com/artifact/org.apache.commons/commons-vfs2-jackrabbit1/2.6.0
> > > > > >>>
> > > > > >>> There's apparently also a Jackrabbit 2 version available:
> > > > > >>>
> > >
> https://mvnrepository.com/artifact/org.apache.commons/commons-vfs2-jackrabbit2/2.6.0
> > > > > >>>
> > > > > >>>
> > > > > >>> On 19/01/2020 11:24, Xeno Amess wrote:
> > > > > >>>> Right now I'm using something like
> > > > > >>>> this to deal with relative files.
> > > > > >>>> But I just think there might be a more elegant way...
> > > > > >>>>
> > > > > >>>> fileSystemManager = new
> > > > > >>>> org.apache.commons.vfs2.impl.StandardFileSystemManager();
> > > > > >>>> fileSystemManager.setLogger(null);
> > > > > >>>> try {
> > > > > >>>> fileSystemManager.init();
> > > > > >>>> fileSystemManager.setBaseFile(new File(""));
> > > > > >>>> } catch (FileSystemException e) {
> > > > > >>>> e.printStackTrace();
> > > > > >>>> }
> > > > > >>>>
> > > > > >>>> Xeno Amess <xenoam...@gmail.com> 于2020年1月19日周日 下午6:08写道：
> > > > > >>>>>
> > > > > >>>>> I'm trying to migrate to commons-vfs2 now
> > > > > >>>>> severial things I found not quite right / amazing.
> > > > > >>>>>
> > > > > >>>>> 1.
> > > > > >>>>> I tested version 2.6.0 and 2.5.0, and I just start at
> > > > > >>>>> VSF.getManager() (of cause I have no additional contfigure or
> > > > > >>>>> something)
> > > > > >>>>>
> > > > > >>>>> It said class not
> > > > > >>>>>
> found:org.apache.commons.vfs2.provider.webdav.WebdavFileProvider
> > > > > >>>>>
> > > > > >>>>> And I looked into your binary jars I get from maven central
> > > (2.6.0).
> > > > > >>>>>
> > > > > >>>>> they really do not have that class WebdavFileProvider.
> > > > > >>>>> (even not found that package
> > > org.apache.commons.vfs2.provider.webdav)
> > > > > >>>>>
> > > > > >>>>> And after I downgrade to 2.3 (I really wonder why 2.3 not
> 2.3.0
> > > but
> > > > > >>>>> that is not important)
> > > > > >>>>> It can run now.(and never tell me class not found again)
> > > > > >>>>> I dont't want to try 2.4.0. Really bad connection here(I'm
> in a
> > > villige now).
> > > > > >>>>> All I get is:
> > > > > >>>>> 2.6.0, broken.
> > > > > >>>>> 2.5.0, broken.
> > > > > >>>>> 2.3, fine.
> > > > > >>>>>
> > > > > >>>>> According to the file on github, it said it might be
> deprecated,
> > > so I
> > > > > >>>>> wonder if you already deprecate d it and you just forgotten
> it?
> > > > > >>>>>
> > > > > >>>>> btw, according to your webpage
> > > https://commons.apache.org/proper/commons-vfs/
> > > > > >>>>> there even do not exist 2.6.0
> > > > > >>>>> But there be a 2.6.0 in maven central.
> > > > > >>>>> really make me confused.
> > > > > >>>>>
> > > > > >>>>> 2.
> > > > > >>>>> for using commons-vfs2 I downgrade slf4j from 2.0.0alpha to
> > > 1.7.30
> > > > > >>>>> We all know slf4j's author really do not care about backward
> > > > > >>>>> maintenance or something.
> > > > > >>>>> His codes are never able to migrate.
> > > > > >>>>> even though, will there be some plan about using reflect or
> > > something
> > > > > >>>>> to make vfs2 CAN suit slf4j 2.0?
> > > > > >>>>>
> > > > > >>>>> 3.
> > > > > >>>>> for some reason I need to deal with relative file path.
> > > > > >>>>> Is there any guide about using relative file path in vfs2?
> > > > > >>>>
> > > > > >>>>
> > > ---------------------------------------------------------------------
> > > > > >>>> 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
> > > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > 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
>
>
