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