[vfs] have some test failures when build with linux root user
Hi, all I'm trying to build the commons-vfs project by use maven command (mvn clean install) and I get some test failures. One of these failures came from org.apache.commons.vfs2.filter.CanReadFileFilterTest.testAcceptReadOnly() and it seems the reason is : 1. the test case create a read-only file 2. the test case check is this read-only file writable and it returns true, so the test case fail. I found this failure is related to root user. The test will pass if I don't run as root user.
Re: [CSV] The Feature Multiple-Character Delimiter
On Wed, 13 May 2020 at 00:27, Gary Gregory wrote:
>
> Hi,
>
> May you give an example where more than one character is used as a
> separator? Is there a database or known tool out there that uses such a
> format?
The IBAN Registry (TXT) located at:
https://www.swift.com/standards/data-standards/iban
uses \r\n as EOL.
Some of the fields include \n within quoted values.
> WRT escaping I would think that \ escapes the one character that follows
> only. It is up to the reader to decide what to do with an escape sequence.
> Anyone else?
>
> Gary
>
> On Tue, May 12, 2020 at 7:42 AM Chen Guoping1
> wrote:
>
> > Hi, all
> >
> >
> >
> >
> > In CSV parsing, there are many scenarios where multiple characters are
> > used as separators,
> >
> > To support this feature, we should change the char type of delimiter to
> > String. This will lead to
> >
> > API changes, and old usage code may need to be modified to pass.
> >
> >
> >
> >
> > When parsing we can get the character array in advance through
> > lookAhead(int n) in the
> >
> > ExtendedBufferedReader to determine whether it is a delimiter
> >
> >
> >
> >
> > char[] lookAhead(int n) throws IOException {
> >
> > char[] buf = new char[n];
> >
> > super.mark(n);
> >
> > super.read(buf, 0, n);
> >
> > super.reset();
> >
> > return buf;
> >
> > }
> >
> >
> >
> >
> > I have a little problem to confirm. The escape character is' \ ', when
> > delimiter is a char ','
> > printWithEscape print '\,' , so when delimiter is multiple characters
> > "[|]" printWithEscape
> > print ’“\[\|\]” or print "\[|]"? I'd prefer to print "\[\|\]". Is there
> > more any suggestion about
> > this feature ?
> >
> >
> > ——
> > Chen Guoping
> >
> >
> >
> >
> >
> >
> >
> >
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [vfs] have some test failures when build with linux root user
Hello, I guess we can document this on the site, I would not change the tests as running with root is a unusual thing to do, anyway. Gruss Bernd -- http://bernd.eckenfels.net Von: shuming chen Gesendet: Wednesday, May 13, 2020 12:20:46 PM An: dev@commons.apache.org Betreff: [vfs] have some test failures when build with linux root user Hi, all I'm trying to build the commons-vfs project by use maven command (mvn clean install) and I get some test failures. One of these failures came from org.apache.commons.vfs2.filter.CanReadFileFilterTest.testAcceptReadOnly() and it seems the reason is : 1. the test case create a read-only file 2. the test case check is this read-only file writable and it returns true, so the test case fail. I found this failure is related to root user. The test will pass if I don't run as root user.
[COMPRESS] Travis build fail with JDK14
Hi,all The travis build of Compress is failing now cause the openjdk14 was added to travis.yml recently. The reason is the Pack200 was removed from JDK14 and there was a discussion about it in January. Emmanuel is working on his replacement project(https://github.com/pack200/pack200) but not finished yet. Seems we have no good replacement for now. I'm thinking we should disable openjdk14 in travis before we have find a solution for this. WDYT?
Re: [COMPRESS] Travis build fail with JDK14
I think there is a bigger question here - Does commons-compress support Java 14? If it does, then the relevant code should be updated to raise an error on JDK 14 which should be expected in the test if on JDK 14. If commons-compress doesn't support Java 14, that should likely be stated somewhere clearly and then JDK 14 could be removed from Travis On Wed, 13 May 2020 at 14:28, Peter Lee wrote: > > Hi,all > > The travis build of Compress is failing now cause the openjdk14 was added > to travis.yml recently. The reason is the Pack200 was removed from JDK14 > and there was a discussion about it in January. Emmanuel is working on his > replacement project(https://github.com/pack200/pack200) but not finished > yet. Seems we have no good replacement for now. > > I'm thinking we should disable openjdk14 in travis before we have find a > solution for this. WDYT? -- Adam Retter skype: adam.retter tweet: adamretter http://www.adamretter.org.uk - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re:Re: [CSV] The Feature Multiple-Character Delimiter
Hi,
As shown in the following figure, MySQL supports multi character separator
import and export：
And about
[CSV-206](https://issues.apache.org/jira/projects/CSV/issues/CSV-206?filter=allopenissues),
StackOverflow
(https://stackoverflow.com/questions/8653797/java-csv-parser-with-string-separator-multi-character).
There are people
looking for support for multi character separators.
It can be found in [CSV-206] that
CsvHelper(https://github.com/JoshClose/CsvHelper) supports multi character
separator,
and
miller(https://github.com/johnkerl/miller/blob/master/c/input/line_readers.h)
also supprot. But It seems that there is
no Java library support yet.
Do commons CSV consider support?
Chen
At 2020-05-13 07:27:26, "Gary Gregory" wrote:
>Hi,
>
>May you give an example where more than one character is used as a
>separator? Is there a database or known tool out there that uses such a
>format?
>
>WRT escaping I would think that \ escapes the one character that follows
>only. It is up to the reader to decide what to do with an escape sequence.
>Anyone else?
>
>Gary
>
>On Tue, May 12, 2020 at 7:42 AM Chen Guoping1
>wrote:
>
>> Hi, all
>>
>>
>>
>>
>> In CSV parsing, there are many scenarios where multiple characters are
>> used as separators,
>>
>> To support this feature, we should change the char type of delimiter to
>> String. This will lead to
>>
>> API changes, and old usage code may need to be modified to pass.
>>
>>
>>
>>
>> When parsing we can get the character array in advance through
>> lookAhead(int n) in the
>>
>> ExtendedBufferedReader to determine whether it is a delimiter
>>
>>
>>
>>
>> char[] lookAhead(int n) throws IOException {
>>
>> char[] buf = new char[n];
>>
>> super.mark(n);
>>
>> super.read(buf, 0, n);
>>
>> super.reset();
>>
>> return buf;
>>
>> }
>>
>>
>>
>>
>> I have a little problem to confirm. The escape character is' \ ', when
>> delimiter is a char ','
>> printWithEscape print '\,' , so when delimiter is multiple characters
>> "[|]" printWithEscape
>> print ’“\[\|\]” or print "\[|]"? I'd prefer to print "\[\|\]". Is there
>> more any suggestion about
>> this feature ?
>>
>>
>> ——
>> Chen Guoping
>>
>>
>>
>>
>>
>>
>>
>>
Re: [CSV] Add ignoreEmptyColumnsLines behavior
On Tue, 12 May 2020 at 10:13, Chen Guoping1 wrote: > > Hi, all > > > About Commons CSV > [CSV-261](https://issues.apache.org/jira/projects/CSV/issues/CSV-261?filter=allopenissues) > Here is a usage scenario that ignores all empty values lines like "，，，\r\n" > in the CSV file, This behavior is very > useful. So we can consider supporting it in Commons CSV. > I have a preliminary implementation, which is to add ignoreEmptyColumnsLines > in CSVFormat, and then filter the > records which are all empty values in CSVParser. you can review the code in > https://issues.apache.org/jira/secure/attachment/13002690/CSV-261-dota17.diff > what do everybody think of this ? > Whilst it may be useful, it seems to me to be out of scope for CSV. It should be easy enough to filter the output to skip empty lines. > - > Chen Guoping > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [CSV] The Feature Multiple-Character Delimiter
On Wed, May 13, 2020 at 6:48 AM sebb wrote:
> On Wed, 13 May 2020 at 00:27, Gary Gregory wrote:
> >
> > Hi,
> >
> > May you give an example where more than one character is used as a
> > separator? Is there a database or known tool out there that uses such a
> > format?
>
> The IBAN Registry (TXT) located at:
> https://www.swift.com/standards/data-standards/iban
> uses \r\n as EOL.
>
> Some of the fields include \n within quoted values.
>
Chen,
Are you talking about record separators, field separators, or both?
Gary
>
> > WRT escaping I would think that \ escapes the one character that follows
> > only. It is up to the reader to decide what to do with an escape
> sequence.
> > Anyone else?
> >
> > Gary
> >
> > On Tue, May 12, 2020 at 7:42 AM Chen Guoping1
> > wrote:
> >
> > > Hi, all
> > >
> > >
> > >
> > >
> > > In CSV parsing, there are many scenarios where multiple characters are
> > > used as separators,
> > >
> > > To support this feature, we should change the char type of delimiter to
> > > String. This will lead to
> > >
> > > API changes, and old usage code may need to be modified to pass.
> > >
> > >
> > >
> > >
> > > When parsing we can get the character array in advance through
> > > lookAhead(int n) in the
> > >
> > > ExtendedBufferedReader to determine whether it is a delimiter
> > >
> > >
> > >
> > >
> > > char[] lookAhead(int n) throws IOException {
> > >
> > > char[] buf = new char[n];
> > >
> > > super.mark(n);
> > >
> > > super.read(buf, 0, n);
> > >
> > > super.reset();
> > >
> > > return buf;
> > >
> > > }
> > >
> > >
> > >
> > >
> > > I have a little problem to confirm. The escape character is' \ ', when
> > > delimiter is a char ','
> > > printWithEscape print '\,' , so when delimiter is multiple characters
> > > "[|]" printWithEscape
> > > print ’“\[\|\]” or print "\[|]"? I'd prefer to print "\[\|\]". Is there
> > > more any suggestion about
> > > this feature ?
> > >
> > >
> > > ——
> > > Chen Guoping
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
Re: [apache/commons-email] consider about putting it to github?
On Sun, 10 May 2020 at 22:23, Xeno Amess wrote: > > thanks > then please change the descriptions in > https://commons.apache.org/proper/commons-email/source-repository.html to > avoid these kind of things. Done on live site. Note: To avoid replacing the entire site, I generated the updated page from pom.xml. The page is now called scm.html, so to avoid breaking menu links I copied the relevant body section only to https://svn.apache.org/repos/infra/websites/production/commons/content/proper/commons-email/source-repository.html and pushed the updated site. > Gilles Sadowski 于2020年5月11日周一 上午5:18写道： > > > 2020-05-10 23:13 UTC+02:00, Xeno Amess : > > > Hi. > > > I see no newer release are made for this project for several years. > > > So I have several questions. > > > 1. Is this project still alive? > > > 2. Should we move it to github? > > > 3. Link http://svn.apache.org/viewvc/commons/proper/email/trunk said 403 > > > forbidden to me, does that means usual user cannot get the repo? > > > svn command line also fails. > > >>svn checkout https://svn.apache.org/repos/asf/commons/proper/email/trunk > > > commons-email > > > svn: E17: URL ' > > > https://svn.apache.org/repos/asf/commons/proper/email/trunk' doesn't > > exist > > > > https://gitbox.apache.org/repos/asf?p=commons-email.git > > > > HTH, > > Gilles > > > > > > > > 4.Yes I can see the released codes, but with no commit history. > > > > > > Thanks. > > > > > > > - > > 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
Re: [COMPRESS] Travis build fail with JDK14
On 2020-05-13, Peter Lee wrote: > Hi,all > The travis build of Compress is failing now cause the openjdk14 was added > to travis.yml recently. The reason is the Pack200 was removed from JDK14 > and there was a discussion about it in January. Emmanuel is working on his > replacement project(https://github.com/pack200/pack200) but not finished > yet. Seems we have no good replacement for now. > I'm thinking we should disable openjdk14 in travis before we have find a > solution for this. WDYT? I'm fine with disabling the travis build for now. Had a quick look through JIRA as I was totally sure there must be an issue tracking this, but it seems I haven't created any. Anyway with the last release announcement I promised we'd deal with JDK14 for the next release - one way or the other. :-) Stefan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [COMPRESS] Travis build fail with JDK14
my opinion: until you are sure the master can pass jdk14, move it to [allow failure]. here is an example. https://github.com/apache/commons-vfs/commit/249d1dc9fb3f2bd5209aaa299c4ed61414f1fd78#diff-354f30a63fb0907d4ad57269548329e3 adding a unpassable check in travis will makes all pull requests/commit return builld failure, which will hide problem and make checker's life hard. Stefan Bodewig 于2020年5月13日周三 下午10:46写道： > On 2020-05-13, Peter Lee wrote: > > > Hi,all > > > The travis build of Compress is failing now cause the openjdk14 was added > > to travis.yml recently. The reason is the Pack200 was removed from JDK14 > > and there was a discussion about it in January. Emmanuel is working on > his > > replacement project(https://github.com/pack200/pack200) but not finished > > yet. Seems we have no good replacement for now. > > > I'm thinking we should disable openjdk14 in travis before we have find a > > solution for this. WDYT? > > I'm fine with disabling the travis build for now. > > Had a quick look through JIRA as I was totally sure there must be an > issue tracking this, but it seems I haven't created any. Anyway with the > last release announcement I promised we'd deal with JDK14 for the next > release - one way or the other. :-) > > Stefan > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
Re: [COMPRESS] Travis build fail with JDK14
I created a pr. https://github.com/apache/commons-compress/pull/100 Xeno Amess 于2020年5月14日周四 上午12:00写道： > my opinion: until you are sure the master can pass jdk14, move it to > [allow failure]. > here is an example. > > https://github.com/apache/commons-vfs/commit/249d1dc9fb3f2bd5209aaa299c4ed61414f1fd78#diff-354f30a63fb0907d4ad57269548329e3 > > > adding a unpassable check in travis will makes all pull requests/commit > return builld failure, which will hide problem and make checker's life hard. > > Stefan Bodewig 于2020年5月13日周三 下午10:46写道： > >> On 2020-05-13, Peter Lee wrote: >> >> > Hi,all >> >> > The travis build of Compress is failing now cause the openjdk14 was >> added >> > to travis.yml recently. The reason is the Pack200 was removed from JDK14 >> > and there was a discussion about it in January. Emmanuel is working on >> his >> > replacement project(https://github.com/pack200/pack200) but not >> finished >> > yet. Seems we have no good replacement for now. >> >> > I'm thinking we should disable openjdk14 in travis before we have find a >> > solution for this. WDYT? >> >> I'm fine with disabling the travis build for now. >> >> Had a quick look through JIRA as I was totally sure there must be an >> issue tracking this, but it seems I haven't created any. Anyway with the >> last release announcement I promised we'd deal with JDK14 for the next >> release - one way or the other. :-) >> >> Stefan >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >>
Re: [COMPRESS] Travis build fail with JDK14
> adding a unpassable check in travis will makes all pull requests/commit > return builld failure, which will hide problem and make checker's life hard. I think this is a good solution for now. > If commons-compress doesn't support Java 14, that should likely be > stated somewhere clearly and then JDK 14 could be removed from Travis Unfortunately it seems commons-compress can not build on Java14. Maybe we should provide a statement about this in README or somewhere else? On Thu, May 14, 2020 at 12:36 AM Xeno Amess wrote: > I created a pr. > https://github.com/apache/commons-compress/pull/100 > > Xeno Amess 于2020年5月14日周四 上午12:00写道： > > > my opinion: until you are sure the master can pass jdk14, move it to > > [allow failure]. > > here is an example. > > > > > https://github.com/apache/commons-vfs/commit/249d1dc9fb3f2bd5209aaa299c4ed61414f1fd78#diff-354f30a63fb0907d4ad57269548329e3 > > > > > > adding a unpassable check in travis will makes all pull requests/commit > > return builld failure, which will hide problem and make checker's life > hard. > > > > Stefan Bodewig 于2020年5月13日周三 下午10:46写道： > > > >> On 2020-05-13, Peter Lee wrote: > >> > >> > Hi,all > >> > >> > The travis build of Compress is failing now cause the openjdk14 was > >> added > >> > to travis.yml recently. The reason is the Pack200 was removed from > JDK14 > >> > and there was a discussion about it in January. Emmanuel is working on > >> his > >> > replacement project(https://github.com/pack200/pack200) but not > >> finished > >> > yet. Seems we have no good replacement for now. > >> > >> > I'm thinking we should disable openjdk14 in travis before we have > find a > >> > solution for this. WDYT? > >> > >> I'm fine with disabling the travis build for now. > >> > >> Had a quick look through JIRA as I was totally sure there must be an > >> issue tracking this, but it seems I haven't created any. Anyway with the > >> last release announcement I promised we'd deal with JDK14 for the next > >> release - one way or the other. :-) > >> > >> Stefan > >> > >> - > >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > >> For additional commands, e-mail: dev-h...@commons.apache.org > >> > >> >
Re: [COMPRESS] Travis build fail with JDK14
On 2020-05-14, Peter Lee wrote: > Unfortunately it seems commons-compress can not build on Java14. Maybe we > should provide a statement about this in README or somewhere else? Done. Also I added something to the "known limitations" page and will re-generate the website. Stefan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Jenkins build is back to normal : Commons-Compress-Windows » Apache Commons Compress #731
there doesn't seem to be a JDK 7 for Windows in our Jenkins farm anymore https://cwiki.apache.org/confluence/display/INFRA/JDK+Installation+Matrix I've made the Windows build use JDK 8 and we now rely on the Linux build to catch JDK 7 incompatibilites. Stefan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re:[CSV] The Feature Multiple-Character Delimiter
At 2020-05-13 22:29:20, "Gary Gregory" wrote:
>On Wed, May 13, 2020 at 6:48 AM sebb wrote:
>
>
>Chen,
>
>Are you talking about record separators, field separators, or both?
>
>Gary
>
Hi, all
Sorry, field seperators.
It is the problem described by
[CSV-206](https://issues.apache.org/jira/projects/CSV/issues/CSV-206)
Chen
At 2020-05-13 22:29:20, "Gary Gregory" wrote:
>On Wed, May 13, 2020 at 6:48 AM sebb wrote:
>
>> On Wed, 13 May 2020 at 00:27, Gary Gregory wrote:
>> >
>> > Hi,
>> >
>> > May you give an example where more than one character is used as a
>> > separator? Is there a database or known tool out there that uses such a
>> > format?
>>
>> The IBAN Registry (TXT) located at:
>> https://www.swift.com/standards/data-standards/iban
>> uses \r\n as EOL.
>>
>> Some of the fields include \n within quoted values.
>>
>
>Chen,
>
>Are you talking about record separators, field separators, or both?
>
>Gary
>
>
>>
>> > WRT escaping I would think that \ escapes the one character that follows
>> > only. It is up to the reader to decide what to do with an escape
>> sequence.
>> > Anyone else?
>> >
>> > Gary
>> >
>> > On Tue, May 12, 2020 at 7:42 AM Chen Guoping1
>> > wrote:
>> >
>> > > Hi, all
>> > >
>> > >
>> > >
>> > >
>> > > In CSV parsing, there are many scenarios where multiple characters are
>> > > used as separators,
>> > >
>> > > To support this feature, we should change the char type of delimiter to
>> > > String. This will lead to
>> > >
>> > > API changes, and old usage code may need to be modified to pass.
>> > >
>> > >
>> > >
>> > >
>> > > When parsing we can get the character array in advance through
>> > > lookAhead(int n) in the
>> > >
>> > > ExtendedBufferedReader to determine whether it is a delimiter
>> > >
>> > >
>> > >
>> > >
>> > > char[] lookAhead(int n) throws IOException {
>> > >
>> > > char[] buf = new char[n];
>> > >
>> > > super.mark(n);
>> > >
>> > > super.read(buf, 0, n);
>> > >
>> > > super.reset();
>> > >
>> > > return buf;
>> > >
>> > > }
>> > >
>> > >
>> > >
>> > >
>> > > I have a little problem to confirm. The escape character is' \ ', when
>> > > delimiter is a char ','
>> > > printWithEscape print '\,' , so when delimiter is multiple characters
>> > > "[|]" printWithEscape
>> > > print ’“\[\|\]” or print "\[|]"? I'd prefer to print "\[\|\]". Is there
>> > > more any suggestion about
>> > > this feature ?
>> > >
>> > >
>> > > ——
>> > > Chen Guoping
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>
