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
