Re: [VOTE] Release Apache Commons DbUtils 1.8 based on RC2

[William Speirs]

Works for me... Carl, let me know how I can help.

On Wed, Jan 22, 2020 at 12:37 AM Carl Hall  wrote:

> I’m in favor of releasing 1.8 because it’s ready and has had the most
> attention in recent months/years.
> After such, we put eyes on the 2.0 branch to ensure it is ready to be the
> successive version. Once we’re happy with that, create a 1.x brach from
> master, bring 2.0 to master, and see if we can get a 2.0 release out before
> 2 more years.  :)
>
> > On Jan 11, 2020, at 10:29 AM, William Speirs  wrote:
> >
> > What is there to "clean up"? Sorry, just not following exactly what you
> > mean.
> >
> > Thanks!
> >
> > Bill-
> >
> > On Fri, Jan 10, 2020 at 4:42 PM Gary Gregory 
> wrote:
> >
> >> I think we should clean all of this up _now_ and then release 1.8.
> >>
> >> What do others think?
> >>
> >> Gary
> >>
> >> On Fri, Jan 10, 2020 at 12:44 PM Carl Hall  wrote:
> >>
> >>> +1 to moving master to 1.8-SNAPSHOT and dealing with what's to come
> with
> >>> 2.0 at some future time in a 2.0 branch.
> >>>
> >>> I can change master:pom.xml to be 1.8-SNAPSHOT then when the RC is out,
> >>> merge release into master (1.8) and proceed to 1.9-SNAPSHOT. Advice?
> >>>
> >>>
> >>> The branch name is a review miss on my part. The command to see RC2 is:
> >>>
> >>> $ git clone https://gitbox.apache.org/repos/asf/commons-dbutils.git
> >>> --branch DBUTILS_1_8_RC2 commons-dbutils-1.8-RC2
> >>>
> >>> The commons plugin generates a tag that doesn't match dbutils' history,
> >>> but I didn't notice that until after RC1 and didn't want to change tag
> >>> formats mid release. I think future releases should use the tag name
> >> format
> >>> from the commons plugin (e.g. commons-dbutils-1.8-RC2) and abandon the
> >>> previous format (e.g. DBUTILS_1_8_RC2).
> >>>
> >>> Thanks for the help with this RC cycle. Clearly every couple of years
> is
> >>> not enough practice. :-)
> >>>
> >>>
>  On Jan 10, 2020, at 7:17 AM, Bill Speirs 
> >> wrote:
> 
>  My vote would be to make master 1.8-SNAPSHOT as I doubt 2.x will see
> >> the
>  light-of-day for a LONG time... it's been 3+ years already. Continue
> >> with
>  what Carl is trying to do, so we at least get _something_ out the
> door.
> 
>  Also, I _think_ I had to create 2_0 as the branch name, because svn
> (at
> >>> the
>  time) wouldn't let me use a dot... but I _might_ be mis-remembering.
> 
>  Bill-
> 
>  On Fri, Jan 10, 2020 at 9:28 AM Gary Gregory 
> >>> wrote:
> 
> > On Fri, Jan 10, 2020 at 9:16 AM William Speirs 
> >>> wrote:
> >
> >> For what it's worth, I'm unable to find that branch in git:
> >>
> >> $ git clone https://gitbox.apache.org/repos/asf/commons-dbutils.git
> >> --branch <
> > https://gitbox.apache.org/repos/asf/commons-dbutils.git--branch>
> >> commons-dbutils-1.8-RC2 commons-dbutils-1.8-RC2
> >> Cloning into 'commons-dbutils-1.8-RC2'...
> >> fatal: Remote branch commons-dbutils-1.8-RC2 not found in upstream
> >>> origin
> >>
> >> After cloning the repo, listing remote branches doesn't show
> >> anything:
> >>
> >> $ git branch -r
> >> origin/2_0
> >> origin/HEAD -> origin/master
> >> origin/master
> >> origin/release
> >>
> >> Bill-
> >>
> >
> > Right, I think we need to hit the pause button here and sort out 1.x
> >>> versus
> > a desired 2.0.
> >
> > Since there is a what looks like a 2.0 branch and our current release
> >> is
> > 1.x, I would assume that this release vote is being made from the
> >>> release
> > branch which has been merged from master.
> >
> > But that does not seem to be the case, right? Since the pom.xml in
> >>> master
> > is 2.0-SNAPSHOT that would seem to indicate that the release branch
> >>> comes
> > from elsewhere, a 1.x branch? No, we do not have one.
> >
> > It feels to me like we should have one of either:
> >
> > - branch master is 1.8-SNAPSHOT, merged into branch release. The 2.0
> >>> work
> > should be in branch 2_0 (which should renamed to 2.x IMO) until it is
> > ready, package name change and all.
> > or:
> > - branch master is 2.0-SNAPSHOT. A currently non-existing branch 1.x
> >>> would
> > contain 1.x and branch release would come a merge of branch 1.x.
> >
> > What do others think? The waters are too muddy for my scuba
> capability
> >>> ATM
> > ;-)
> >
> > Gary
> >
> >
> >>
> >> On Fri, Jan 10, 2020 at 3:56 AM Bruno P. Kinoshita <
> ki...@apache.org
> >>>
> >> wrote:
> >>
> >>>   [x] +1 Release these artifacts
> >>>
> >>>
> >>> Build passing with JDK 13 on Ubuntu LTS, from git tag (mvn clean
> >> test
> >>> install site). Reports look OK.
> >>>
> >>>
> >>> There are two SpotBugs bugs about default encoding that can be
> fixed
> >> later
> >>> I suppose. Generating reports locally skipped PMD. For some reason,
> >>

Re: [VOTE] Release Apache Commons DbUtils 1.8 based on RC2

[Carl Hall]

Thanks, Bill. Looking for 2 more positive votes to proceed. :)  I'd like to 
hear from Gary given his concerns on this thread.


> On Jan 22, 2020, at 6:00 AM, William Speirs  wrote:
> 
> Works for me... Carl, let me know how I can help.
> 
> On Wed, Jan 22, 2020 at 12:37 AM Carl Hall  wrote:
> 
>> I’m in favor of releasing 1.8 because it’s ready and has had the most
>> attention in recent months/years.
>> After such, we put eyes on the 2.0 branch to ensure it is ready to be the
>> successive version. Once we’re happy with that, create a 1.x brach from
>> master, bring 2.0 to master, and see if we can get a 2.0 release out before
>> 2 more years.  :)
>> 
>>> On Jan 11, 2020, at 10:29 AM, William Speirs  wrote:
>>> 
>>> What is there to "clean up"? Sorry, just not following exactly what you
>>> mean.
>>> 
>>> Thanks!
>>> 
>>> Bill-
>>> 
>>> On Fri, Jan 10, 2020 at 4:42 PM Gary Gregory 
>> wrote:
>>> 
 I think we should clean all of this up _now_ and then release 1.8.
 
 What do others think?
 
 Gary
 
 On Fri, Jan 10, 2020 at 12:44 PM Carl Hall  wrote:
 
> +1 to moving master to 1.8-SNAPSHOT and dealing with what's to come
>> with
> 2.0 at some future time in a 2.0 branch.
> 
> I can change master:pom.xml to be 1.8-SNAPSHOT then when the RC is out,
> merge release into master (1.8) and proceed to 1.9-SNAPSHOT. Advice?
> 
> 
> The branch name is a review miss on my part. The command to see RC2 is:
> 
> $ git clone https://gitbox.apache.org/repos/asf/commons-dbutils.git
> --branch DBUTILS_1_8_RC2 commons-dbutils-1.8-RC2
> 
> The commons plugin generates a tag that doesn't match dbutils' history,
> but I didn't notice that until after RC1 and didn't want to change tag
> formats mid release. I think future releases should use the tag name
 format
> from the commons plugin (e.g. commons-dbutils-1.8-RC2) and abandon the
> previous format (e.g. DBUTILS_1_8_RC2).
> 
> Thanks for the help with this RC cycle. Clearly every couple of years
>> is
> not enough practice. :-)
> 
> 
>> On Jan 10, 2020, at 7:17 AM, Bill Speirs 
 wrote:
>> 
>> My vote would be to make master 1.8-SNAPSHOT as I doubt 2.x will see
 the
>> light-of-day for a LONG time... it's been 3+ years already. Continue
 with
>> what Carl is trying to do, so we at least get _something_ out the
>> door.
>> 
>> Also, I _think_ I had to create 2_0 as the branch name, because svn
>> (at
> the
>> time) wouldn't let me use a dot... but I _might_ be mis-remembering.
>> 
>> Bill-
>> 
>> On Fri, Jan 10, 2020 at 9:28 AM Gary Gregory 
> wrote:
>> 
>>> On Fri, Jan 10, 2020 at 9:16 AM William Speirs 
> wrote:
>>> 
 For what it's worth, I'm unable to find that branch in git:
 
 $ git clone https://gitbox.apache.org/repos/asf/commons-dbutils.git
 --branch <
>>> https://gitbox.apache.org/repos/asf/commons-dbutils.git--branch>
 commons-dbutils-1.8-RC2 commons-dbutils-1.8-RC2
 Cloning into 'commons-dbutils-1.8-RC2'...
 fatal: Remote branch commons-dbutils-1.8-RC2 not found in upstream
> origin
 
 After cloning the repo, listing remote branches doesn't show
 anything:
 
 $ git branch -r
 origin/2_0
 origin/HEAD -> origin/master
 origin/master
 origin/release
 
 Bill-
 
>>> 
>>> Right, I think we need to hit the pause button here and sort out 1.x
> versus
>>> a desired 2.0.
>>> 
>>> Since there is a what looks like a 2.0 branch and our current release
 is
>>> 1.x, I would assume that this release vote is being made from the
> release
>>> branch which has been merged from master.
>>> 
>>> But that does not seem to be the case, right? Since the pom.xml in
> master
>>> is 2.0-SNAPSHOT that would seem to indicate that the release branch
> comes
>>> from elsewhere, a 1.x branch? No, we do not have one.
>>> 
>>> It feels to me like we should have one of either:
>>> 
>>> - branch master is 1.8-SNAPSHOT, merged into branch release. The 2.0
> work
>>> should be in branch 2_0 (which should renamed to 2.x IMO) until it is
>>> ready, package name change and all.
>>> or:
>>> - branch master is 2.0-SNAPSHOT. A currently non-existing branch 1.x
> would
>>> contain 1.x and branch release would come a merge of branch 1.x.
>>> 
>>> What do others think? The waters are too muddy for my scuba
>> capability
> ATM
>>> ;-)
>>> 
>>> Gary
>>> 
>>> 
 
 On Fri, Jan 10, 2020 at 3:56 AM Bruno P. Kinoshita <
>> ki...@apache.org
> 
 wrote:
 
>  [x] +1 Release these artifacts
> 
> 
> Build passing with JDK 13 on Ubuntu LTS, from git tag (mvn clean

Release of Commons Crypto

[Alex Remily]

How do we go about getting a release for Commons Crypto?

Re: [codec] Base32/Base64 trailing bit validation is incomplete

[Alex Herbert]

This has turned out to be non-trivial. Current progress in in PR [1].


Easy

- Added a property to BaseNCodec to enable strict decoding

All other properties of the codec are set in the constructor and are final. So 
using a property is a change. I can change to overloaded constructors but there 
are already a lot of these so a property or builder type pattern is cleaner e.g:

// Returns a new codec with strict decoding, all other properties the same
Base64 withStrictDecoding();

I can remove the isStrictEncoding() method. However this would have to replaced 
by the package/protected level access to the property for Base32/Base64. Other 
properties in the class are protected. So maybe drop the isStrictEncoding() 
method and change the accessor level for the property. However there is another 
property in Base64 (isUrlSafe()) so properties are not excluded from the design 
pattern.

- Added tests to show Base64 strict mode works

This is fine. Base64 encoding cannot create a final 6-bit character. Previously 
this was ignored. It now optionally throws in strict mode.

All other validation of trailing 12 or 18 bits works. I added tests to show 
that a decoded byte[] is re-encoded to the same byte[] when in strict mode but 
not in lenient mode.


Issues

- Added tests to show Base32 strict mode works

It does. It also shows that the current decoder is capable of decoding 
non-sense.

Referring to the final section for the encode method shows encoding can create 
a count of 2, 4, 5, or 7 trailing characters. So a valid Base32 encoding will 
never have 1, 3, or 6 trailing characters.

Previously 1 trailing character was ignored. It now optionally throws. So far, 
so good.

But the previous behaviour for 3 or 6 trailing characters is to decode them 
into as many bytes as is possible. This does not make sense. They could only 
have come from an invalid encoding:

3 chars = 15-bits = 1 byte and 7 remainder. So this should have used 2 trailing 
characters and a pad.
6 chars = 30-bits = 3 bytes and 6 remainder. So this should have used 5 
trailing characters and a pad.

In the PR I have preserved this behaviour for lenient mode. This is backwards 
compatible. In strict mode this will now throw. So lenient mode is allowing 
non-pad characters to act as padding in certain cases.

As before I added tests to show that a decoded byte[] is re-encoded to the same 
byte[] when in strict mode but not in lenient mode.


Unresolved

Base64 is used by codec.net.BCodec. This also had tests for impossible 
encodings. These now fail as the default is to revert to lenient mode.

So this requires a decision on whether BCodec should:

- Regress to lenient mode
- Move to strict mode and throw more exceptions than before
- Also add a property to enable strict mode


Have a look at the PR and give some suggestions.

Alex



[1] https://github.com/apache/commons-codec/pull/35 

Re: [VOTE] Release Apache Commons DbUtils 1.8 based on RC2

[William Speirs]

Sorry, meant to say: +1

On Wed, Jan 22, 2020 at 7:34 PM Carl Hall  wrote:

> Thanks, Bill. Looking for 2 more positive votes to proceed. :)  I'd like
> to hear from Gary given his concerns on this thread.
>
>
> > On Jan 22, 2020, at 6:00 AM, William Speirs  wrote:
> >
> > Works for me... Carl, let me know how I can help.
> >
> > On Wed, Jan 22, 2020 at 12:37 AM Carl Hall  wrote:
> >
> >> I’m in favor of releasing 1.8 because it’s ready and has had the most
> >> attention in recent months/years.
> >> After such, we put eyes on the 2.0 branch to ensure it is ready to be
> the
> >> successive version. Once we’re happy with that, create a 1.x brach from
> >> master, bring 2.0 to master, and see if we can get a 2.0 release out
> before
> >> 2 more years.  :)
> >>
> >>> On Jan 11, 2020, at 10:29 AM, William Speirs 
> wrote:
> >>>
> >>> What is there to "clean up"? Sorry, just not following exactly what you
> >>> mean.
> >>>
> >>> Thanks!
> >>>
> >>> Bill-
> >>>
> >>> On Fri, Jan 10, 2020 at 4:42 PM Gary Gregory 
> >> wrote:
> >>>
>  I think we should clean all of this up _now_ and then release 1.8.
> 
>  What do others think?
> 
>  Gary
> 
>  On Fri, Jan 10, 2020 at 12:44 PM Carl Hall 
> wrote:
> 
> > +1 to moving master to 1.8-SNAPSHOT and dealing with what's to come
> >> with
> > 2.0 at some future time in a 2.0 branch.
> >
> > I can change master:pom.xml to be 1.8-SNAPSHOT then when the RC is
> out,
> > merge release into master (1.8) and proceed to 1.9-SNAPSHOT. Advice?
> >
> >
> > The branch name is a review miss on my part. The command to see RC2
> is:
> >
> > $ git clone https://gitbox.apache.org/repos/asf/commons-dbutils.git
> > --branch DBUTILS_1_8_RC2 commons-dbutils-1.8-RC2
> >
> > The commons plugin generates a tag that doesn't match dbutils'
> history,
> > but I didn't notice that until after RC1 and didn't want to change
> tag
> > formats mid release. I think future releases should use the tag name
>  format
> > from the commons plugin (e.g. commons-dbutils-1.8-RC2) and abandon
> the
> > previous format (e.g. DBUTILS_1_8_RC2).
> >
> > Thanks for the help with this RC cycle. Clearly every couple of years
> >> is
> > not enough practice. :-)
> >
> >
> >> On Jan 10, 2020, at 7:17 AM, Bill Speirs 
>  wrote:
> >>
> >> My vote would be to make master 1.8-SNAPSHOT as I doubt 2.x will see
>  the
> >> light-of-day for a LONG time... it's been 3+ years already. Continue
>  with
> >> what Carl is trying to do, so we at least get _something_ out the
> >> door.
> >>
> >> Also, I _think_ I had to create 2_0 as the branch name, because svn
> >> (at
> > the
> >> time) wouldn't let me use a dot... but I _might_ be mis-remembering.
> >>
> >> Bill-
> >>
> >> On Fri, Jan 10, 2020 at 9:28 AM Gary Gregory <
> garydgreg...@gmail.com>
> > wrote:
> >>
> >>> On Fri, Jan 10, 2020 at 9:16 AM William Speirs  >
> > wrote:
> >>>
>  For what it's worth, I'm unable to find that branch in git:
> 
>  $ git clone
> https://gitbox.apache.org/repos/asf/commons-dbutils.git
>  --branch <
> >>> https://gitbox.apache.org/repos/asf/commons-dbutils.git--branch>
>  commons-dbutils-1.8-RC2 commons-dbutils-1.8-RC2
>  Cloning into 'commons-dbutils-1.8-RC2'...
>  fatal: Remote branch commons-dbutils-1.8-RC2 not found in upstream
> > origin
> 
>  After cloning the repo, listing remote branches doesn't show
>  anything:
> 
>  $ git branch -r
>  origin/2_0
>  origin/HEAD -> origin/master
>  origin/master
>  origin/release
> 
>  Bill-
> 
> >>>
> >>> Right, I think we need to hit the pause button here and sort out
> 1.x
> > versus
> >>> a desired 2.0.
> >>>
> >>> Since there is a what looks like a 2.0 branch and our current
> release
>  is
> >>> 1.x, I would assume that this release vote is being made from the
> > release
> >>> branch which has been merged from master.
> >>>
> >>> But that does not seem to be the case, right? Since the pom.xml in
> > master
> >>> is 2.0-SNAPSHOT that would seem to indicate that the release branch
> > comes
> >>> from elsewhere, a 1.x branch? No, we do not have one.
> >>>
> >>> It feels to me like we should have one of either:
> >>>
> >>> - branch master is 1.8-SNAPSHOT, merged into branch release. The
> 2.0
> > work
> >>> should be in branch 2_0 (which should renamed to 2.x IMO) until it
> is
> >>> ready, package name change and all.
> >>> or:
> >>> - branch master is 2.0-SNAPSHOT. A currently non-existing branch
> 1.x
> > would
> >>> contain 1.x and branch release would come a merge of branch 1.x.
> >>>
> >>> What do others think? The waters are

Re: some questions (/bug?) about commons-vfs2 make me confused.

[Xeno Amess]

and there comes one more question:
how to transfer a FileObject(vfs) to a File(in Java) (if possible)?
I know that sonds insane but sometimes we just need a function like this.
I tried

try {
result = new File(fileObject.getURL().toURI());
} catch (URISyntaxException | FileSystemException e) {
LOGGER.error("this FileObject cannot be transformed to a File", e);
}

it works in normal cases but when your path contains character space
in them, it will throw URISyntaxException
seems vfs and java holds different rules about space in file path?
and how should I achieve this?

Xeno Amess  于2020年1月20日周一 上午12:41写道：
>
> 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  于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  于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  于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  于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 

Re: some questions (/bug?) about commons-vfs2 make me confused.

[Bernd Eckenfels]

Hello,

If you represent a local file then I think you can use

   fileObj.getName().getPathDecoded()

However it might be a good idea to add a method like

   File fileSystemManager.toFile(FileObject)

As the reverse of FileObject fsm.toFileObject(File).

Ps: usage questions are better on commons-user mailing list.

Gruss
Bernd



--
http://bernd.eckenfels.net

Von: Xeno Amess 
Gesendet: Thursday, January 23, 2020 3:02:02 AM
An: Commons Developers List 
Betreff: Re: some questions (/bug?) about commons-vfs2 make me confused.

and there comes one more question:
how to transfer a FileObject(vfs) to a File(in Java) (if possible)?
I know that sonds insane but sometimes we just need a function like this.
I tried

try {
result = new File(fileObject.getURL().toURI());
} catch (URISyntaxException | FileSystemException e) {
LOGGER.error("this FileObject cannot be transformed to a File", e);
}

it works in normal cases but when your path contains character space
in them, it will throw URISyntaxException
seems vfs and java holds different rules about space in file path?
and how should I achieve this?

Xeno Amess  于2020年1月20日周一 上午12:41写道：
>
> 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  于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  于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  于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  于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 n