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
