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
