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