[jira] [Commented] (NET-725) Variable FILE_LIST_REGEX in class MVSFTPEntryParser must be changed
[ https://issues.apache.org/jira/browse/NET-725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17764996#comment-17764996 ] Andreas Wagner commented on NET-725: Hi [Gary D. Gregory|https://issues.apache.org/jira/secure/ViewProfile.jspa?name=ggregory]! Thanks for merging the PR. I still have the following questions: # Is there a delivery date/release for the current fixes yet? # Should this ticket be closed now or remain open until the official delivery? > Variable FILE_LIST_REGEX in class MVSFTPEntryParser must be changed > --- > > Key: NET-725 > URL: https://issues.apache.org/jira/browse/NET-725 > Project: Commons Net > Issue Type: Bug > Components: FTP >Affects Versions: 3.9.0 >Reporter: Andreas Wagner >Priority: Major > > Hello! > I have found two problems when connected to an MVS ftp server and using > client method "listFiles()". > 1) Some files are not listed on ftp client side because not all possible MVS > dataset RECFM options are considered in class MVSFTPEntryParser. > 2) Migrated MVS datasets are not listed on ftp client side > Detailed information for prolem 1 (not all possible RECFM options are > considered): > The final string variable FILE_LIST_REGEX in class MVSFTPEntryParser is > missing RECFM options. Therefore, valid dataset names are currently not > correctly recognized and therefore not processed (e.g. when using method > "listFiles()"). > The definition of the variable must be extended as follows. > Current definition: > static final string FILE_LIST_REGEX = "\\S+\\s+" + // volume - ignored > "\\S+\s+" + // unit - ignored > "\\S+\\s+" + // access date - ignored > "\\S+\s+" + // extents -ignored > // If the values are too large, the fields may be merged (NET-639) > "(?:\\S+\\s+)?" + // used - ignored > "(?:F|FB|V|VB|U)\\s+" + // recfm - F[B], V[B], U > "\\S+\\s+" + // logical record length -ignored > "\\S+\s+" + // block size - ignored > "(PS|PO|PO-E)\\s+" + // Dataset organization. Many exist > // but only support: PS, PO, PO-E > "(\\S+)\\s*"; // Dataset name (file name). > Future extended definition: > static final string FILE_LIST_REGEX = "\\S+\\s+" + // volume - ignored > "\\S+\s+" + // unit - ignored > "\\S+\\s+" + // access date - ignored > "\\S+\s+" + // extents -ignored > // If the values are too large, the fields may be merged (NET-639) > "(?:\\S+\\s+)?" + // used - ignored > "(?:F|FA|FB|FBA|V|VA|VB|VBA|VS|VBS|U)\\s+" + // recfm - F[A][B], > V[A][B][S], U > "\\S+\\s+" + // logical record length -ignored > "\\S+\s+" + // block size - ignored > "(PS|PO|PO-E)\\s+" + // Dataset organization. Many exist > // but only support: PS, PO, PO-E > "(\\S+)\\s*"; // Dataset name (file name). > > Detailed information for prolem 2 (migrated MVS datasets are not listed): > Final variable FILE_LIST_REGEX doesn't consider migrated datasets. For > example: when dataset with name "HLQ.DATA.SET.NAME" is migrated on tape the > mvs ftp server return following text to the client: > Migrated 'HLQ.DATA.SET.NAME' > Since RECFM is not known by the ftp server for a migrated dataset the pattern > string stored in FILE_LIST_REGEX doesn't match in this case. But the migrated > datasets are of course valid datasets and therefore should be returned when > calling "listFiles()". At least the name of this (migrated) dataset should be > returned when calling "ftpFile.getName()". > > With kind regards, > Andreas Wagner -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CSV-310) Misleading error message when QuoteMode set to None
[
https://issues.apache.org/jira/browse/CSV-310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17764962#comment-17764962
]
Buddhi De Silva commented on CSV-310:
-
PR Approved and changes are reflected in the master branch.
Closing the ticket.
> Misleading error message when QuoteMode set to None
> ---
>
> Key: CSV-310
> URL: https://issues.apache.org/jira/browse/CSV-310
> Project: Commons CSV
> Issue Type: Improvement
> Components: Parser
>Affects Versions: 1.10.0
>Reporter: Buddhi De Silva
>Priority: Minor
> Labels: easy-fix, formatter,
> Fix For: 1.10.1
>
>
> When we try to print CSV content using the _CSVFormat_ and {_}CSVPrinter{_},
> we can ger it done with following sample code.
> {code:java}
> public void testHappyPath() throws IOException {
> CSVFormat csvFormat = CSVFormat.DEFAULT.builder()
> .setHeader("Col1", "Col2", "Col3", "Col4")
> .setQuoteMode(QuoteMode.NONE)
> .setEscape('#')
> .build(); CSVPrinter printer = new CSVPrinter(System.out,
> csvFormat); List temp = new ArrayList<>(); temp.add(new
> String[] { "rec1", "rec2\"", "", "rec4" });
> temp.add(new String[] { "", "rec6", "rec7", "rec8" }); for (String[]
> temp1 : temp) {
> printer.printRecord(temp1);
> }
> printer.close();
> } {code}
> In above sample I have used 'setQuoteMode(QuoteMode.NONE)'. However, if we do
> not set the escape character using 'setEscape('#')' then it would result in
> following exception.
> {code:java}
> java.lang.IllegalArgumentException: No quotes mode set but no escape
> character is set. {code}
> At first, I was wondering why I was getting this error. Then I looked into
> the source and figured out that _CSVFormat.printWithEscapes()_ method
> internaly using _getEscapeCharacter().charValue()_ method to print records.
>
> However, the error message which we are getting is sort of misleading. It
> implies that the code has not set any quote mode even though we set it.
> Simple and more meaningful exception message could be: "Quote mode set to
> NONE but no escape character is set".
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (CSV-310) Misleading error message when QuoteMode set to None
[
https://issues.apache.org/jira/browse/CSV-310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Buddhi De Silva closed CSV-310.
---
> Misleading error message when QuoteMode set to None
> ---
>
> Key: CSV-310
> URL: https://issues.apache.org/jira/browse/CSV-310
> Project: Commons CSV
> Issue Type: Improvement
> Components: Parser
>Affects Versions: 1.10.0
>Reporter: Buddhi De Silva
>Priority: Minor
> Labels: easy-fix, formatter,
> Fix For: 1.10.1
>
>
> When we try to print CSV content using the _CSVFormat_ and {_}CSVPrinter{_},
> we can ger it done with following sample code.
> {code:java}
> public void testHappyPath() throws IOException {
> CSVFormat csvFormat = CSVFormat.DEFAULT.builder()
> .setHeader("Col1", "Col2", "Col3", "Col4")
> .setQuoteMode(QuoteMode.NONE)
> .setEscape('#')
> .build(); CSVPrinter printer = new CSVPrinter(System.out,
> csvFormat); List temp = new ArrayList<>(); temp.add(new
> String[] { "rec1", "rec2\"", "", "rec4" });
> temp.add(new String[] { "", "rec6", "rec7", "rec8" }); for (String[]
> temp1 : temp) {
> printer.printRecord(temp1);
> }
> printer.close();
> } {code}
> In above sample I have used 'setQuoteMode(QuoteMode.NONE)'. However, if we do
> not set the escape character using 'setEscape('#')' then it would result in
> following exception.
> {code:java}
> java.lang.IllegalArgumentException: No quotes mode set but no escape
> character is set. {code}
> At first, I was wondering why I was getting this error. Then I looked into
> the source and figured out that _CSVFormat.printWithEscapes()_ method
> internaly using _getEscapeCharacter().charValue()_ method to print records.
>
> However, the error message which we are getting is sort of misleading. It
> implies that the code has not set any quote mode even though we set it.
> Simple and more meaningful exception message could be: "Quote mode set to
> NONE but no escape character is set".
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CSV-147) Better error message during faulty CSV record read
[
https://issues.apache.org/jira/browse/CSV-147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17764960#comment-17764960
]
Buddhi De Silva commented on CSV-147:
-
PR Approved.
This issue need to be verified and closed by the reporter.
> Better error message during faulty CSV record read
> --
>
> Key: CSV-147
> URL: https://issues.apache.org/jira/browse/CSV-147
> Project: Commons CSV
> Issue Type: Improvement
> Components: Parser
>Affects Versions: 1.1
>Reporter: Steven Peterson
>Priority: Major
> Labels: easyfix
> Fix For: 1.10.1
>
> Attachments: csv-exceptionsupport.patch
>
> Original Estimate: 0.25h
> Remaining Estimate: 0.25h
>
> When parsing long files, and there is problem with parsing the data, it would
> be very useful to know the exact data that is bad when an exception is
> thrown. As CSVParser maintains a portion of the current record that was read
> when an exception is thrown (in the 'record' property), can we make this
> information public through something like this:
> {code:java}
> public String[] getLastRecordData() {
> return this.record.toArray(new String[this.record.size()]);
> }
> {code}
> With a method like this, it would be easy to pull in part of the data that
> was in the faulty record after an exception was thrown, aiding in cleaning up
> the data.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [commons-beanutils] garydgregory commented on pull request #40: Replace Commons Collections Test Framework 3.2.2 with 4.4
garydgregory commented on PR #40: URL: https://github.com/apache/commons-beanutils/pull/40#issuecomment-1718349287 TY @melloware ! -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-beanutils] garydgregory merged pull request #40: Remove Commons Collections Test Framework
garydgregory merged PR #40: URL: https://github.com/apache/commons-beanutils/pull/40 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-beanutils] melloware commented on pull request #40: Remove Commons Collections Test Framework
melloware commented on PR #40: URL: https://github.com/apache/commons-beanutils/pull/40#issuecomment-1718281508 @gary since this PR is over 3 years old I am editing it in GitHub I don't even have this project checked out anymore. I know you are busy and I appreciate all you do for commons but a 3 year old PR is pretty disappointing. Thus you get GitHub edits. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-beanutils] garydgregory commented on pull request #40: Remove Commons Collections Test Framework
garydgregory commented on PR #40: URL: https://github.com/apache/commons-beanutils/pull/40#issuecomment-1718271314 Please run a local build before you push, it's annoying to see builds fail because of compilation failures ;-) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-beanutils] garydgregory commented on a diff in pull request #40: Remove Commons Collections Test Framework
garydgregory commented on code in PR #40:
URL: https://github.com/apache/commons-beanutils/pull/40#discussion_r1325040673
##
src/test/java/org/apache/commons/beanutils2/collections/AbstractObjectTest.java:
##
@@ -0,0 +1,338 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.commons.beanutils2.collections;
+
+import java.io.ByteArrayInputStream;
+import java.io.ByteArrayOutputStream;
+import java.io.File;
+import java.io.FileInputStream;
+import java.io.FileOutputStream;
+import java.io.IOException;
+import java.io.InputStream;
+import java.io.ObjectInputStream;
+import java.io.ObjectOutputStream;
+import java.io.OutputStream;
+import java.io.Serializable;
+
+/**
+ * Abstract test class for {@link java.lang.Object} methods and contracts.
+ *
+ * To use, simply extend this class, and implement
+ * the {@link #makeObject()} method.
+ *
+ * If your {@link Object} fails one of these tests by design,
+ * you may still use this base set of cases. Simply override the
+ * test case (method) your {@link Object} fails.
+ *
+ * Copied from Commons Collection 4.
+ * @see https://github.com/apache/commons-collections/blob/master/src/test/java/org/apache/commons/collections4/AbstractObjectTest.java";>AbstractObjectTest.java
Review Comment:
Of course, it shows up:
https://search.maven.org/search?q=fc:org.apache.commons.collections4.AbstractObjectTest
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [commons-beanutils] melloware commented on a diff in pull request #40: Remove Commons Collections Test Framework
melloware commented on code in PR #40:
URL: https://github.com/apache/commons-beanutils/pull/40#discussion_r1325038480
##
src/test/java/org/apache/commons/beanutils2/collections/AbstractObjectTest.java:
##
@@ -0,0 +1,338 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.commons.beanutils2.collections;
+
+import java.io.ByteArrayInputStream;
+import java.io.ByteArrayOutputStream;
+import java.io.File;
+import java.io.FileInputStream;
+import java.io.FileOutputStream;
+import java.io.IOException;
+import java.io.InputStream;
+import java.io.ObjectInputStream;
+import java.io.ObjectOutputStream;
+import java.io.OutputStream;
+import java.io.Serializable;
+
+/**
+ * Abstract test class for {@link java.lang.Object} methods and contracts.
+ *
+ * To use, simply extend this class, and implement
+ * the {@link #makeObject()} method.
+ *
+ * If your {@link Object} fails one of these tests by design,
+ * you may still use this base set of cases. Simply override the
+ * test case (method) your {@link Object} fails.
+ *
+ * Copied from Commons Collection 4.
+ * @see https://github.com/apache/commons-collections/blob/master/src/test/java/org/apache/commons/collections4/AbstractObjectTest.java";>AbstractObjectTest.java
Review Comment:
O. I see its actually a `test` I don't love
when libraries do this because its not advertised nor does it show up on Maven
Central Searches! Yeah @landsman most of the classes can be removed and that
added to pom.xml now.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [commons-beanutils] garydgregory commented on a diff in pull request #40: Remove Commons Collections Test Framework
garydgregory commented on code in PR #40:
URL: https://github.com/apache/commons-beanutils/pull/40#discussion_r1325035182
##
src/test/java/org/apache/commons/beanutils2/collections/AbstractObjectTest.java:
##
@@ -0,0 +1,338 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.commons.beanutils2.collections;
+
+import java.io.ByteArrayInputStream;
+import java.io.ByteArrayOutputStream;
+import java.io.File;
+import java.io.FileInputStream;
+import java.io.FileOutputStream;
+import java.io.IOException;
+import java.io.InputStream;
+import java.io.ObjectInputStream;
+import java.io.ObjectOutputStream;
+import java.io.OutputStream;
+import java.io.Serializable;
+
+/**
+ * Abstract test class for {@link java.lang.Object} methods and contracts.
+ *
+ * To use, simply extend this class, and implement
+ * the {@link #makeObject()} method.
+ *
+ * If your {@link Object} fails one of these tests by design,
+ * you may still use this base set of cases. Simply override the
+ * test case (method) your {@link Object} fails.
+ *
+ * Copied from Commons Collection 4.
+ * @see https://github.com/apache/commons-collections/blob/master/src/test/java/org/apache/commons/collections4/AbstractObjectTest.java";>AbstractObjectTest.java
Review Comment:
I would not mention it if it didn't exist...
https://repo1.maven.org/maven2/org/apache/commons/commons-collections4/4.4/
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [commons-beanutils] melloware commented on a diff in pull request #40: Remove Commons Collections Test Framework
melloware commented on code in PR #40:
URL: https://github.com/apache/commons-beanutils/pull/40#discussion_r1325031243
##
src/test/java/org/apache/commons/beanutils2/collections/AbstractObjectTest.java:
##
@@ -0,0 +1,338 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.commons.beanutils2.collections;
+
+import java.io.ByteArrayInputStream;
+import java.io.ByteArrayOutputStream;
+import java.io.File;
+import java.io.FileInputStream;
+import java.io.FileOutputStream;
+import java.io.IOException;
+import java.io.InputStream;
+import java.io.ObjectInputStream;
+import java.io.ObjectOutputStream;
+import java.io.OutputStream;
+import java.io.Serializable;
+
+/**
+ * Abstract test class for {@link java.lang.Object} methods and contracts.
+ *
+ * To use, simply extend this class, and implement
+ * the {@link #makeObject()} method.
+ *
+ * If your {@link Object} fails one of these tests by design,
+ * you may still use this base set of cases. Simply override the
+ * test case (method) your {@link Object} fails.
+ *
+ * Copied from Commons Collection 4.
+ * @see https://github.com/apache/commons-collections/blob/master/src/test/java/org/apache/commons/collections4/AbstractObjectTest.java";>AbstractObjectTest.java
Review Comment:
I didn't think there was one? Isn't that why we did this their "test" jar
no longer exists in Maven they got rid of it?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [commons-beanutils] garydgregory commented on a diff in pull request #40: Remove Commons Collections Test Framework
garydgregory commented on code in PR #40:
URL: https://github.com/apache/commons-beanutils/pull/40#discussion_r1325019951
##
src/test/java/org/apache/commons/beanutils2/collections/AbstractObjectTest.java:
##
@@ -0,0 +1,338 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.commons.beanutils2.collections;
+
+import java.io.ByteArrayInputStream;
+import java.io.ByteArrayOutputStream;
+import java.io.File;
+import java.io.FileInputStream;
+import java.io.FileOutputStream;
+import java.io.IOException;
+import java.io.InputStream;
+import java.io.ObjectInputStream;
+import java.io.ObjectOutputStream;
+import java.io.OutputStream;
+import java.io.Serializable;
+
+/**
+ * Abstract test class for {@link java.lang.Object} methods and contracts.
+ *
+ * To use, simply extend this class, and implement
+ * the {@link #makeObject()} method.
+ *
+ * If your {@link Object} fails one of these tests by design,
+ * you may still use this base set of cases. Simply override the
+ * test case (method) your {@link Object} fails.
+ *
+ * Copied from Commons Collection 4.
+ * @see https://github.com/apache/commons-collections/blob/master/src/test/java/org/apache/commons/collections4/AbstractObjectTest.java";>AbstractObjectTest.java
Review Comment:
@melloware
Then just add a test dependency on the Commons Collection test jar ;-)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [commons-beanutils] melloware commented on a diff in pull request #40: Remove Commons Collections Test Framework
melloware commented on code in PR #40:
URL: https://github.com/apache/commons-beanutils/pull/40#discussion_r1325009841
##
src/test/java/org/apache/commons/beanutils2/collections/AbstractObjectTest.java:
##
@@ -0,0 +1,338 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.commons.beanutils2.collections;
+
+import java.io.ByteArrayInputStream;
+import java.io.ByteArrayOutputStream;
+import java.io.File;
+import java.io.FileInputStream;
+import java.io.FileOutputStream;
+import java.io.IOException;
+import java.io.InputStream;
+import java.io.ObjectInputStream;
+import java.io.ObjectOutputStream;
+import java.io.OutputStream;
+import java.io.Serializable;
+
+/**
+ * Abstract test class for {@link java.lang.Object} methods and contracts.
+ *
+ * To use, simply extend this class, and implement
+ * the {@link #makeObject()} method.
+ *
+ * If your {@link Object} fails one of these tests by design,
+ * you may still use this base set of cases. Simply override the
+ * test case (method) your {@link Object} fails.
+ *
+ * Copied from Commons Collection 4.
+ * @see https://github.com/apache/commons-collections/blob/master/src/test/java/org/apache/commons/collections4/AbstractObjectTest.java";>AbstractObjectTest.java
Review Comment:
If I remember its a test only `/src/test/java` class in Commons Collections
so it is not in the JAR file.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [commons-beanutils] garydgregory commented on a diff in pull request #40: Remove Commons Collections Test Framework
garydgregory commented on code in PR #40:
URL: https://github.com/apache/commons-beanutils/pull/40#discussion_r1325004037
##
src/test/java/org/apache/commons/beanutils2/collections/AbstractObjectTest.java:
##
@@ -0,0 +1,338 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.commons.beanutils2.collections;
+
+import java.io.ByteArrayInputStream;
+import java.io.ByteArrayOutputStream;
+import java.io.File;
+import java.io.FileInputStream;
+import java.io.FileOutputStream;
+import java.io.IOException;
+import java.io.InputStream;
+import java.io.ObjectInputStream;
+import java.io.ObjectOutputStream;
+import java.io.OutputStream;
+import java.io.Serializable;
+
+/**
+ * Abstract test class for {@link java.lang.Object} methods and contracts.
+ *
+ * To use, simply extend this class, and implement
+ * the {@link #makeObject()} method.
+ *
+ * If your {@link Object} fails one of these tests by design,
+ * you may still use this base set of cases. Simply override the
+ * test case (method) your {@link Object} fails.
+ *
+ * Copied from Commons Collection 4.
+ * @see https://github.com/apache/commons-collections/blob/master/src/test/java/org/apache/commons/collections4/AbstractObjectTest.java";>AbstractObjectTest.java
Review Comment:
Why is this copied when we depend on Commons Collection 4?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [commons-beanutils] melloware commented on pull request #40: Remove Commons Collections Test Framework
melloware commented on PR #40: URL: https://github.com/apache/commons-beanutils/pull/40#issuecomment-1718160684 Thanks @landsman ! -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-text] theshoeshiner commented on a diff in pull request #450: Cases API + 4 implementations (Pascal, Camel, Kebab, Snake)
theshoeshiner commented on code in PR #450: URL: https://github.com/apache/commons-text/pull/450#discussion_r1324802675 ## src/main/java/org/apache/commons/text/cases/CamelCase.java: ## @@ -0,0 +1,121 @@ +/* + * Licensed to the Apache Software Foundation (ASF) under one or more + * contributor license agreements. See the NOTICE file distributed with + * this work for additional information regarding copyright ownership. + * The ASF licenses this file to You under the Apache License, Version 2.0 + * (the "License"); you may not use this file except in compliance with + * the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, software + * distributed under the License is distributed on an "AS IS" BASIS, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the License for the specific language governing permissions and + * limitations under the License. + */ +package org.apache.commons.text.cases; + +import java.util.ArrayList; +import java.util.List; + +import org.apache.commons.lang3.CharUtils; +import org.apache.commons.lang3.StringUtils; + +/** + * Case implementation that parses and formats strings of the form 'myCamelCase' + * + * This case separates tokens on uppercase ASCII alpha characters. Each token begins with an Review Comment: So, in making this change, I ran into another quirk. Unicode has 3 cases (UPPER, lower, and Title). In my updated implementation, I was only handling upper and lower. i.e. in order to convert the token `Xabc` into a Pascal string, the `X` character _must_ translate to (or already be) an uppercase character. However, one might argue that having a titlecase character is also sufficient, since the purpose of the Pascal case is to uppercase only the first character, which is also the purpose of unicode titlecase. So this string `dzabc` (note that "dz" is the single digraph character) could be represented as either: - **DZ**abc (dz to uppercase) - **Dz**abc (dz to titlecase) For that specific character we have two possible options, however there are also lowercase characters whose uppercase character is of the **titlecase** category. Which means anywhere we use the `Character.isUpperCase` check, it will fail, despite the fact that kinda works. I see a couple questions / decisions... - Should we allow titlecase characters to serve as uppercase when uppercase doesn't exist? - Should we _prefer_ unicode titlecase over uppercase when both exist? - Should the user be able to choose? (In all cases, if a character cannot be mapped to lowercase, then logic that requires it will throw an exception). FWIW - my inclination is to handle only upper/lower case. Title case feels more like a feature of proper grammar, and this library makes no such assumptions. A character is a character, and in reality we have no clue what language the user is using. So `dzabc` would transform/output to `DZabc`. The user needs to be aware either way that they're using Unicode and that DZ is a single character. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-text] theshoeshiner commented on a diff in pull request #450: Cases API + 4 implementations (Pascal, Camel, Kebab, Snake)
theshoeshiner commented on code in PR #450: URL: https://github.com/apache/commons-text/pull/450#discussion_r1324802675 ## src/main/java/org/apache/commons/text/cases/CamelCase.java: ## @@ -0,0 +1,121 @@ +/* + * Licensed to the Apache Software Foundation (ASF) under one or more + * contributor license agreements. See the NOTICE file distributed with + * this work for additional information regarding copyright ownership. + * The ASF licenses this file to You under the Apache License, Version 2.0 + * (the "License"); you may not use this file except in compliance with + * the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, software + * distributed under the License is distributed on an "AS IS" BASIS, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the License for the specific language governing permissions and + * limitations under the License. + */ +package org.apache.commons.text.cases; + +import java.util.ArrayList; +import java.util.List; + +import org.apache.commons.lang3.CharUtils; +import org.apache.commons.lang3.StringUtils; + +/** + * Case implementation that parses and formats strings of the form 'myCamelCase' + * + * This case separates tokens on uppercase ASCII alpha characters. Each token begins with an Review Comment: So, in making this change, I ran into another quirk. Unicode has 3 cases (UPPER, Lower, and Title). In my updated implementation, I was only handling upper and lower. i.e. in order to convert the token `Xabc` into a Pascal string, the `X` character _must_ translate to (or already be) an uppercase character. However, one might argue that having a titlecase character is also sufficient, since the purpose of the Pascal case is to uppercase only the first character, which is also the purpose of unicode titlecase. So this string `dzabc` (note that "dz" is the single digraph character) could be represented as either: - **DZ**abc (dz to uppercase) - **Dz**abc (dz to titlecase) For that specific character we have two possible options, however there are also lowercase characters whose uppercase character is of the **titlecase** category. Which means anywhere we use the `Character.isUpperCase` check, it will fail, despite the fact that kinda works. I see a couple questions / decisions... - Should we allow titlecase characters to serve as uppercase? - Should we _prefer_ unicode titlecase over uppercase when both exist? - Should the user be able to choose? (In all cases, if a character cannot be mapped to lowercase, then logic that requires it will throw an exception). FWIW - my inclination is to handle only upper/lower case. Title case feels more like a feature of proper grammar, and this library makes no such assumptions. A character is a character, and in reality we have no clue what language the user is using. So `dzabc` would transform/output to `DZabc`. The user needs to be aware either way that they're using Unicode and that DZ is a single character. ## src/main/java/org/apache/commons/text/cases/CamelCase.java: ## @@ -0,0 +1,121 @@ +/* + * Licensed to the Apache Software Foundation (ASF) under one or more + * contributor license agreements. See the NOTICE file distributed with + * this work for additional information regarding copyright ownership. + * The ASF licenses this file to You under the Apache License, Version 2.0 + * (the "License"); you may not use this file except in compliance with + * the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, software + * distributed under the License is distributed on an "AS IS" BASIS, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the License for the specific language governing permissions and + * limitations under the License. + */ +package org.apache.commons.text.cases; + +import java.util.ArrayList; +import java.util.List; + +import org.apache.commons.lang3.CharUtils; +import org.apache.commons.lang3.StringUtils; + +/** + * Case implementation that parses and formats strings of the form 'myCamelCase' + * + * This case separates tokens on uppercase ASCII alpha characters. Each token begins with an Review Comment: So, in making this change, I ran into another quirk. Unicode has 3 cases (UPPER, lower, and Title). In my updated implementation, I was only handling upper and lower. i.e. in order to convert the token `Xabc` into a Pascal string, the `X` character _must_ translate to (or already be) an uppercase character. However, one might argue that having a titlecase character is also sufficient, since the purpose of the Pascal case is to uppercase only the first character, which is also t
[GitHub] [commons-text] theshoeshiner commented on a diff in pull request #450: Cases API + 4 implementations (Pascal, Camel, Kebab, Snake)
theshoeshiner commented on code in PR #450: URL: https://github.com/apache/commons-text/pull/450#discussion_r1324802675 ## src/main/java/org/apache/commons/text/cases/CamelCase.java: ## @@ -0,0 +1,121 @@ +/* + * Licensed to the Apache Software Foundation (ASF) under one or more + * contributor license agreements. See the NOTICE file distributed with + * this work for additional information regarding copyright ownership. + * The ASF licenses this file to You under the Apache License, Version 2.0 + * (the "License"); you may not use this file except in compliance with + * the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, software + * distributed under the License is distributed on an "AS IS" BASIS, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the License for the specific language governing permissions and + * limitations under the License. + */ +package org.apache.commons.text.cases; + +import java.util.ArrayList; +import java.util.List; + +import org.apache.commons.lang3.CharUtils; +import org.apache.commons.lang3.StringUtils; + +/** + * Case implementation that parses and formats strings of the form 'myCamelCase' + * + * This case separates tokens on uppercase ASCII alpha characters. Each token begins with an Review Comment: So, in making this change, I ran into another quirk. Unicode has 3 cases (UPPER, Lower, and Title). In my updated implementation, I was only handling upper and lower. i.e. in order to convert the token `Xabc` into a Pascal string, the `X` character _must_ translate to (or already be) an uppercase character. However, one might argue that having a titlecase character is also sufficient, since the purpose of the Pascal case is to uppercase only the first character, which is also the purpose of unicode titlecase. So this string `dzabc` (note that "dz" is the single digraph character) could be represented as either: - `DZabc` (dz to uppercase) - `Dzabc` (dz to titlecase) For that specific character we have two possible options, however there are also lowercase characters whose uppercase character is of the **titlecase** category. Which means anywhere we use the `Character.isUpperCase` check, it will fail, despite the fact that kinda works. I see a couple questions / decisions... - Should we allow titlecase characters to serve as uppercase? - Should we _prefer_ unicode titlecase over uppercase when both exist? - Should the user be able to choose? (In all cases, if a character cannot be mapped to lowercase, then logic that requires it will throw an exception). FWIW - my inclination is to handle only upper/lower case. Title case feels more like a feature of proper grammar, and this library makes no such assumptions. A character is a character, and in reality we have no clue what language the user is using. So `dzabc` would transform/output to `DZabc`. The user needs to be aware either way that they're using Unicode and that DZ is a single character. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-text] theshoeshiner commented on a diff in pull request #450: Cases API + 4 implementations (Pascal, Camel, Kebab, Snake)
theshoeshiner commented on code in PR #450: URL: https://github.com/apache/commons-text/pull/450#discussion_r1324802675 ## src/main/java/org/apache/commons/text/cases/CamelCase.java: ## @@ -0,0 +1,121 @@ +/* + * Licensed to the Apache Software Foundation (ASF) under one or more + * contributor license agreements. See the NOTICE file distributed with + * this work for additional information regarding copyright ownership. + * The ASF licenses this file to You under the Apache License, Version 2.0 + * (the "License"); you may not use this file except in compliance with + * the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, software + * distributed under the License is distributed on an "AS IS" BASIS, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the License for the specific language governing permissions and + * limitations under the License. + */ +package org.apache.commons.text.cases; + +import java.util.ArrayList; +import java.util.List; + +import org.apache.commons.lang3.CharUtils; +import org.apache.commons.lang3.StringUtils; + +/** + * Case implementation that parses and formats strings of the form 'myCamelCase' + * + * This case separates tokens on uppercase ASCII alpha characters. Each token begins with an Review Comment: So, in making this change, I ran into another quirk. Unicode has 3 cases (UPPER, Lower, and Title). In my updated implementation, I was only handling upper and lower. i.e. in order to convert the token `Xabc` into a Pascal string, the `X` character _must_ translate to (or already be) an uppercase character. However, one might argue that having a titlecase character is also sufficient, since the purpose of the Pascal case is to uppercase only the first character, which is also the purpose of unicode titlecase. So this string `dzabc` (note that "dz" is the single digraph character) could be represented as either: - DZabc (dz to uppercase) - Dzabc (dz to titlecase) For that specific character we have two possible options, however there are also lowercase characters whose uppercase character is of the **titlecase** category. Which means anywhere we use the `Character.isUpperCase` check, it will fail, despite the fact that kinda works. I see a couple questions / decisions... - Should we allow titlecase characters to serve as uppercase? - Should we _prefer_ unicode titlecase over uppercase when both exist? - Should the user be able to choose? (In all cases, if a character cannot be mapped to lowercase, then logic that requires it will throw an exception). FWIW - my inclination is to handle only upper/lower case. Title case feels more like a feature of proper grammar, and this library makes no such assumptions. A character is a character, and in reality we have no clue what language the user is using. So `dzabc` would transform/output to `DZabc`. The user needs to be aware either way that they're using Unicode and that DZ is a single character. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-text] theshoeshiner commented on a diff in pull request #450: Cases API + 4 implementations (Pascal, Camel, Kebab, Snake)
theshoeshiner commented on code in PR #450: URL: https://github.com/apache/commons-text/pull/450#discussion_r1324802675 ## src/main/java/org/apache/commons/text/cases/CamelCase.java: ## @@ -0,0 +1,121 @@ +/* + * Licensed to the Apache Software Foundation (ASF) under one or more + * contributor license agreements. See the NOTICE file distributed with + * this work for additional information regarding copyright ownership. + * The ASF licenses this file to You under the Apache License, Version 2.0 + * (the "License"); you may not use this file except in compliance with + * the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, software + * distributed under the License is distributed on an "AS IS" BASIS, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the License for the specific language governing permissions and + * limitations under the License. + */ +package org.apache.commons.text.cases; + +import java.util.ArrayList; +import java.util.List; + +import org.apache.commons.lang3.CharUtils; +import org.apache.commons.lang3.StringUtils; + +/** + * Case implementation that parses and formats strings of the form 'myCamelCase' + * + * This case separates tokens on uppercase ASCII alpha characters. Each token begins with an Review Comment: So, in making this change, I ran into another quirk. Unicode has 3 cases (UPPER, Lower, and Title). In my updated implementation, I was only handling upper and lower. i.e. in order to convert the token `Xabc` into a Pascal string, the `X` character _must_ translate to (or already be) an uppercase character. However, one might argue that having a titlecase character is also sufficient, since the purpose of the Pascal case is to uppercase only the first character, which is also the purpose of unicode titlecase. So this string `dzabc` (note that "dz" is the single digraph character) could be represented as either: - DZabc (dz to uppercase) - Dzabc (dz to titlecase) For that specific character we have two possible options, however there are also lowercase characters whose uppercase character is of the **titlecase** category. Which means anywhere we use the `Character.isUpperCase` check, it will fail, despite the fact that kinda works. I see a couple questions / decisions... - Should we allow titlecase characters to serve as uppercase? - Should we _prefer_ unicode titlecase over uppercase when both exist? - Should the user be able to choose? (In all cases, if a character cannot be mapped to lowercase, then logic that requires it will throw an exception). FWIW - my inclination is to handle only upper/lower case. Title case feels more like a feature of proper grammar, and this library makes no such assumptions. A character is a character, and in reality we have no clue what language the user is using. So dzabc would transform to DZabc. The user needs to be aware either way that they're using Unicode and that DZ is a single character. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-text] theshoeshiner commented on a diff in pull request #450: Cases API + 4 implementations (Pascal, Camel, Kebab, Snake)
theshoeshiner commented on code in PR #450: URL: https://github.com/apache/commons-text/pull/450#discussion_r1324802675 ## src/main/java/org/apache/commons/text/cases/CamelCase.java: ## @@ -0,0 +1,121 @@ +/* + * Licensed to the Apache Software Foundation (ASF) under one or more + * contributor license agreements. See the NOTICE file distributed with + * this work for additional information regarding copyright ownership. + * The ASF licenses this file to You under the Apache License, Version 2.0 + * (the "License"); you may not use this file except in compliance with + * the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, software + * distributed under the License is distributed on an "AS IS" BASIS, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the License for the specific language governing permissions and + * limitations under the License. + */ +package org.apache.commons.text.cases; + +import java.util.ArrayList; +import java.util.List; + +import org.apache.commons.lang3.CharUtils; +import org.apache.commons.lang3.StringUtils; + +/** + * Case implementation that parses and formats strings of the form 'myCamelCase' + * + * This case separates tokens on uppercase ASCII alpha characters. Each token begins with an Review Comment: So, in making this change, I ran into another quirk. Unicode has 3 cases (UPPER, Lower, and Title). In my updated implementation, I was only handling upper and lower. i.e. in order to convert the token `Xabc` into a Pascal string, the `X` character _must_ translate to (or already be) an uppercase character. However, one might argue that having a titlecase character is also sufficient, since the purpose of the Pascal case is to uppercase only the first character, which is also the purpose of unicode titlecase. So this string `dzabc` (note that "dz" is the single digraph character) could be represented as either: - DZabc (dz to uppercase) - Dzabc (dz to titlecase) For that specific character we have two possible options, however there are also lowercase characters whose uppercase character is of the **titlecase** category. Which means anywhere we use the `Character.isUpperCase` check, it will fail, despite the fact that kinda works. I see a couple questions / decisions... - Should we allow titlecase characters to serve as uppercase? - Should we _prefer_ unicode titlecase over uppercase when both exist? - Should the user be able to choose? (In all cases, if a character cannot be mapped to lowercase, then logic that requires it will throw an exception). FWIW - my inclination is to handle only upper/lower case. Title case feels more like a feature of proper grammar, and this library makes no such assumptions. A character is a character, and in reality we have no clue what language the user is using. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-text] theshoeshiner commented on a diff in pull request #450: Cases API + 4 implementations (Pascal, Camel, Kebab, Snake)
theshoeshiner commented on code in PR #450: URL: https://github.com/apache/commons-text/pull/450#discussion_r1324802675 ## src/main/java/org/apache/commons/text/cases/CamelCase.java: ## @@ -0,0 +1,121 @@ +/* + * Licensed to the Apache Software Foundation (ASF) under one or more + * contributor license agreements. See the NOTICE file distributed with + * this work for additional information regarding copyright ownership. + * The ASF licenses this file to You under the Apache License, Version 2.0 + * (the "License"); you may not use this file except in compliance with + * the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, software + * distributed under the License is distributed on an "AS IS" BASIS, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the License for the specific language governing permissions and + * limitations under the License. + */ +package org.apache.commons.text.cases; + +import java.util.ArrayList; +import java.util.List; + +import org.apache.commons.lang3.CharUtils; +import org.apache.commons.lang3.StringUtils; + +/** + * Case implementation that parses and formats strings of the form 'myCamelCase' + * + * This case separates tokens on uppercase ASCII alpha characters. Each token begins with an Review Comment: So, in making this change, I ran into another quirk. Unicode has 3 cases (UPPER, Lower, and Title). In my updated implementation, I was only handling upper and lower. i.e. in order to convert the token `Xabc` into a Pascal string, the `X` character _must_ translate to (or already be) an uppercase character. However, one might argue that having a titlecase character is also sufficient, since the purpose of the Pascal case is to uppercase only the first character, which is also the purpose of unicode titlecase. So this string `dzabc` (note that "dz" is the single digraph character) could be represented as either: - DZabc (dz to uppercase) - Dzabc (dz to titlecase) For that specific character we have two possible options, however there are also lowercase characters whose uppercase character is of the **titlecase** category. Which means anywhere we use the `Character.isUpperCase` check, it will fail, despite the fact that kinda works. I see a couple questions / decisions... - Should we allow titlecase characters to serve as uppercase? - Should we _prefer_ unicode titlecase over uppercase when both exist? - Should the user be able to choose? (In all cases, if a character cannot be mapped to lowercase, then logic that requires it will throw an exception). FWIW - my inclination is to handle only upper/lower case. Title case feels more like a feature of proper grammar, and this library makes no such assumptions. A letter is a letter, and in reality we have no clue what language the user is using. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-text] theshoeshiner commented on a diff in pull request #450: Cases API + 4 implementations (Pascal, Camel, Kebab, Snake)
theshoeshiner commented on code in PR #450: URL: https://github.com/apache/commons-text/pull/450#discussion_r1324802675 ## src/main/java/org/apache/commons/text/cases/CamelCase.java: ## @@ -0,0 +1,121 @@ +/* + * Licensed to the Apache Software Foundation (ASF) under one or more + * contributor license agreements. See the NOTICE file distributed with + * this work for additional information regarding copyright ownership. + * The ASF licenses this file to You under the Apache License, Version 2.0 + * (the "License"); you may not use this file except in compliance with + * the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, software + * distributed under the License is distributed on an "AS IS" BASIS, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the License for the specific language governing permissions and + * limitations under the License. + */ +package org.apache.commons.text.cases; + +import java.util.ArrayList; +import java.util.List; + +import org.apache.commons.lang3.CharUtils; +import org.apache.commons.lang3.StringUtils; + +/** + * Case implementation that parses and formats strings of the form 'myCamelCase' + * + * This case separates tokens on uppercase ASCII alpha characters. Each token begins with an Review Comment: So, in making this change, I ran into another quirk. Unicode has 3 cases (UPPER, Lower, and Title). In my updated implementation, I was only handling upper and lower. i.e. in order to convert the token `Xabc` into a Pascal string, the `X` character _must_ translate to (or already be) an uppercase character. However, one might argue that having a titlecase character is also sufficient, since the purpose of the Pascal case is to uppercase only the first character, which is also the purpose of unicode titlecase. So this string `dzabc` (note that "dz" is the single digraph character) could be represented as either: - DZabc (dz to uppercase) - Dzabc (dz to titlecase) For that specific character we have two possible options, however there are also lowercase characters whose uppercase character is of the **titlecase** category. Which means anywhere we use the `Character.isUpperCase` check, it will fail, despite the fact that kinda works. I see a couple questions / decisions... - Should we allow titlecase characters to serve as uppercase? - Should we _prefer_ unicode titlecase over uppercase when both exist? - Should the user be able to choose? (In all cases, if a character cannot be mapped to lowercase, then logic that requires it will throw an exception). FWIW - my inclination is to handle only upper/lower case. Title case feels more like a feature of proper grammar, and this library makes no such assumptions. A letter is a letter, in reality have no clue what language the user is using. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-text] theshoeshiner commented on a diff in pull request #450: Cases API + 4 implementations (Pascal, Camel, Kebab, Snake)
theshoeshiner commented on code in PR #450: URL: https://github.com/apache/commons-text/pull/450#discussion_r1324802675 ## src/main/java/org/apache/commons/text/cases/CamelCase.java: ## @@ -0,0 +1,121 @@ +/* + * Licensed to the Apache Software Foundation (ASF) under one or more + * contributor license agreements. See the NOTICE file distributed with + * this work for additional information regarding copyright ownership. + * The ASF licenses this file to You under the Apache License, Version 2.0 + * (the "License"); you may not use this file except in compliance with + * the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, software + * distributed under the License is distributed on an "AS IS" BASIS, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the License for the specific language governing permissions and + * limitations under the License. + */ +package org.apache.commons.text.cases; + +import java.util.ArrayList; +import java.util.List; + +import org.apache.commons.lang3.CharUtils; +import org.apache.commons.lang3.StringUtils; + +/** + * Case implementation that parses and formats strings of the form 'myCamelCase' + * + * This case separates tokens on uppercase ASCII alpha characters. Each token begins with an Review Comment: So, in making this change, I ran into another quirk. Unicode has 3 cases (UPPER, Lower, and Title). In my updated implementation, I was only handling upper and lower. i.e. in order to convert the token `Xabc` into a Pascal string, the `X` character _must_ translate to (or already be) an uppercase character. However, one might argue that having a titlecase character is also sufficient, since the purpose of the Pascal case is to uppercase only the first character, which is also the purpose of unicode titlecase. So this string `dzabc` (note that "dz" is the single digraph character) could be represented as either: - DZabc (dz to uppercase) - Dzabc (dz to titlecase) For that specific character we have two possible options, however there are also lowercase characters whose uppercase character is of the **titlecase** category. Which means anywhere we use the `Character.isUpperCase` check, it will fail, despite the fact that kinda works. I see a couple questions / decisions... - Should we allow titlecase characters to serve as uppercase? - Should we _prefer_ unicode titlecase over uppercase when both exist? - Should the user be able to choose? (In all cases, if a character cannot be mapped to lowercase, then logic that requires it will throw an exception). FWIW - my inclination is to only use uppercase. Title case feels more like a feature of proper grammar, and this library makes no such assumptions. A letter is a letter, in reality have no clue what language the user is using. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-text] theshoeshiner commented on a diff in pull request #450: Cases API + 4 implementations (Pascal, Camel, Kebab, Snake)
theshoeshiner commented on code in PR #450: URL: https://github.com/apache/commons-text/pull/450#discussion_r1324802675 ## src/main/java/org/apache/commons/text/cases/CamelCase.java: ## @@ -0,0 +1,121 @@ +/* + * Licensed to the Apache Software Foundation (ASF) under one or more + * contributor license agreements. See the NOTICE file distributed with + * this work for additional information regarding copyright ownership. + * The ASF licenses this file to You under the Apache License, Version 2.0 + * (the "License"); you may not use this file except in compliance with + * the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, software + * distributed under the License is distributed on an "AS IS" BASIS, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the License for the specific language governing permissions and + * limitations under the License. + */ +package org.apache.commons.text.cases; + +import java.util.ArrayList; +import java.util.List; + +import org.apache.commons.lang3.CharUtils; +import org.apache.commons.lang3.StringUtils; + +/** + * Case implementation that parses and formats strings of the form 'myCamelCase' + * + * This case separates tokens on uppercase ASCII alpha characters. Each token begins with an Review Comment: So, in making this change, I ran into another quirk. Unicode has 3 cases (upper, lower, and title). In my updated implementation, I was only handling upper and lower. i.e. in order to convert the token `Xabc` into a Pascal string, the `X` character _must_ translate to (or already be) an uppercase character. However, one might argue that having a titlecase character is also sufficient, since the purpose of the Pascal case is to uppercase only the first character, which is also the purpose of unicode titlecase. So this string `dzabc` (note that "dz" is the single digraph character) could be represented as either: - DZabc (dz to uppercase) - Dzabc (dz to titlecase) For that specific character we have two possible options, however there are also lowercase characters whose uppercase character is of the **titlecase** category. Which means anywhere we use the `Character.isUpperCase` check, it will fail, despite the fact that kinda works. I see a couple questions / decisions... - Should we allow titlecase characters to serve as uppercase? - Should we _prefer_ unicode titlecase over uppercase when both exist? - Should the user be able to choose? (In all cases, if a character cannot be mapped to lowercase, then logic that requires it will throw an exception). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-text] theshoeshiner commented on a diff in pull request #450: Cases API + 4 implementations (Pascal, Camel, Kebab, Snake)
theshoeshiner commented on code in PR #450: URL: https://github.com/apache/commons-text/pull/450#discussion_r1324802675 ## src/main/java/org/apache/commons/text/cases/CamelCase.java: ## @@ -0,0 +1,121 @@ +/* + * Licensed to the Apache Software Foundation (ASF) under one or more + * contributor license agreements. See the NOTICE file distributed with + * this work for additional information regarding copyright ownership. + * The ASF licenses this file to You under the Apache License, Version 2.0 + * (the "License"); you may not use this file except in compliance with + * the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, software + * distributed under the License is distributed on an "AS IS" BASIS, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the License for the specific language governing permissions and + * limitations under the License. + */ +package org.apache.commons.text.cases; + +import java.util.ArrayList; +import java.util.List; + +import org.apache.commons.lang3.CharUtils; +import org.apache.commons.lang3.StringUtils; + +/** + * Case implementation that parses and formats strings of the form 'myCamelCase' + * + * This case separates tokens on uppercase ASCII alpha characters. Each token begins with an Review Comment: So, in making this change, I ran into another quirk. Unicode has 3 cases (UPPER, Lower, and Title). In my updated implementation, I was only handling upper and lower. i.e. in order to convert the token `Xabc` into a Pascal string, the `X` character _must_ translate to (or already be) an uppercase character. However, one might argue that having a titlecase character is also sufficient, since the purpose of the Pascal case is to uppercase only the first character, which is also the purpose of unicode titlecase. So this string `dzabc` (note that "dz" is the single digraph character) could be represented as either: - DZabc (dz to uppercase) - Dzabc (dz to titlecase) For that specific character we have two possible options, however there are also lowercase characters whose uppercase character is of the **titlecase** category. Which means anywhere we use the `Character.isUpperCase` check, it will fail, despite the fact that kinda works. I see a couple questions / decisions... - Should we allow titlecase characters to serve as uppercase? - Should we _prefer_ unicode titlecase over uppercase when both exist? - Should the user be able to choose? (In all cases, if a character cannot be mapped to lowercase, then logic that requires it will throw an exception). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-beanutils] melloware commented on pull request #40: Remove Commons Collections Test Framework
melloware commented on PR #40: URL: https://github.com/apache/commons-beanutils/pull/40#issuecomment-1717968049 Just committed a fix. Watching the build now. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-beanutils] garydgregory commented on pull request #40: Remove Commons Collections Test Framework
garydgregory commented on PR #40: URL: https://github.com/apache/commons-beanutils/pull/40#issuecomment-1717943523 > rebased. Hi @melloware Thank you for the update! The build is broken unfortunately, but it should be an easy fix for you though 😉 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-beanutils] landsman commented on pull request #40: Remove Commons Collections Test Framework
landsman commented on PR #40: URL: https://github.com/apache/commons-beanutils/pull/40#issuecomment-1717913880 @melloware Can you allow me to push your forked repository, please? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-beanutils] landsman commented on pull request #40: Remove Commons Collections Test Framework
landsman commented on PR #40: URL: https://github.com/apache/commons-beanutils/pull/40#issuecomment-1717896912 @melloware thanks, but you did merge, not interactive rebase. Here I tried to to it, with cherry-picked your changes: https://github.com/apache/commons-beanutils/compare/master...landsman:commons-beanutils:master Locally tests passed. I'm not sure what is the best steps here. Should I do PR to yours repository, branch? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-beanutils] melloware commented on pull request #40: Remove Commons Collections Test Framework
melloware commented on PR #40: URL: https://github.com/apache/commons-beanutils/pull/40#issuecomment-1717890263 rebased. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-beanutils] landsman commented on pull request #40: Remove Commons Collections Test Framework
landsman commented on PR #40: URL: https://github.com/apache/commons-beanutils/pull/40#issuecomment-1717848372 I tried to upgrade commons collections to commons-collections4 but changes in `BeanMapTestCase` like this one is needed. I see that there was a lot of effort to make it work. Can you please rebase this PR? I can help with conflicts. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-validator] garydgregory commented on pull request #153: commons-collections4
garydgregory commented on PR #153: URL: https://github.com/apache/commons-validator/pull/153#issuecomment-1717794128 Apache Commons Components normally only break binary compatibility in a new major release, which the justification from going from 3.x to 4.x. When this happens, the Java package name is changed as are the Maven coordinates. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-validator] landsman commented on pull request #153: bump commons-commons-collections-4.4
landsman commented on PR #153: URL: https://github.com/apache/commons-validator/pull/153#issuecomment-1717761621 Great, that's it. Do you know why it's been renamed? It's kinda unclear to me. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-validator] garydgregory commented on pull request #153: bump commons-commons-collections-4.4
garydgregory commented on PR #153: URL: https://github.com/apache/commons-validator/pull/153#issuecomment-1717728952 > I tried to bump this dependency locally of course, but I faced this problem with the missing version on the Maven Repository that I mentioned. > >  > > Yes, I'm aware that's a bad idea, but I don't know a better way to let you know when Issues are not allowed here. You're not looking in the right place ;-) please see https://commons.apache.org/proper/commons-collections/dependency-info.html -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-validator] landsman commented on pull request #153: bump commons-commons-collections-4.4
landsman commented on PR #153: URL: https://github.com/apache/commons-validator/pull/153#issuecomment-1717706244 I tried to bump this dependency locally of course, but I faced this problem with the missing version on the Maven Repository that I mentioned.  Yes, I'm aware that's a bad idea, but I don't know a better way to let you know when Issues are not allowed here. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-validator] garydgregory commented on pull request #153: bump commons-commons-collections-4.4
garydgregory commented on PR #153: URL: https://github.com/apache/commons-validator/pull/153#issuecomment-1717690910 @landsman Please don't submit "blind" PRs. IOW, test your changes locally first using `mvn` from the command line to invoke the default Maven goal, otherwise, you'll be wasting your time and my time writing this ;-) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-validator] landsman commented on pull request #153: bump commons-commons-collections-4.4
landsman commented on PR #153: URL: https://github.com/apache/commons-validator/pull/153#issuecomment-1717661377 Probably @garydgregory will know more about this topic. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-validator] landsman opened a new pull request, #153: bump commons-commons-collections-4.4
landsman opened a new pull request, #153: URL: https://github.com/apache/commons-validator/pull/153 Hello, I noticed in my editor that there is some vulnerability reported.  Problem is that affected dependency [commons-collection](https://github.com/apache/commons-collections) do not have a new releases on maven repository: https://repo.maven.apache.org/maven2/commons-collections/commons-collections/ However there are new releases under bigger tags than original 3.2.2, see: https://github.com/apache/commons-collections/releases/tag/commons-commons-collections-4.4 I don't know why. Can you please check it with the responsible people? I don't know how to connect to the correct mailing list, write there. I would love to write it as a GitHub issue but it's not possible. So I did this dump pull request to let you know, and ask you to help me with that. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-net] garydgregory merged pull request #182: Change Class "org.apache.commons.net.ftp.parser.MVSFTPEntryParser" to support more datasets
garydgregory merged PR #182: URL: https://github.com/apache/commons-net/pull/182 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-lang] garydgregory commented on a diff in pull request #1110: [LANG-1705] SerializationUtils.clone() throws a ClassCastException when override writeReplace()
garydgregory commented on code in PR #1110: URL: https://github.com/apache/commons-lang/pull/1110#discussion_r1324492443 ## pom.xml: ## @@ -624,7 +624,7 @@ src/site/resources/checkstyle -false +true Review Comment: -1, you cannot disable this check within a major release line. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Resolved] (CSV-310) Misleading error message when QuoteMode set to None
[
https://issues.apache.org/jira/browse/CSV-310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory resolved CSV-310.
-
Fix Version/s: 1.10.1
Resolution: Fixed
> Misleading error message when QuoteMode set to None
> ---
>
> Key: CSV-310
> URL: https://issues.apache.org/jira/browse/CSV-310
> Project: Commons CSV
> Issue Type: Improvement
> Components: Parser
>Affects Versions: 1.10.0
>Reporter: Buddhi De Silva
>Priority: Minor
> Labels: easy-fix, formatter,
> Fix For: 1.10.1
>
>
> When we try to print CSV content using the _CSVFormat_ and {_}CSVPrinter{_},
> we can ger it done with following sample code.
> {code:java}
> public void testHappyPath() throws IOException {
> CSVFormat csvFormat = CSVFormat.DEFAULT.builder()
> .setHeader("Col1", "Col2", "Col3", "Col4")
> .setQuoteMode(QuoteMode.NONE)
> .setEscape('#')
> .build(); CSVPrinter printer = new CSVPrinter(System.out,
> csvFormat); List temp = new ArrayList<>(); temp.add(new
> String[] { "rec1", "rec2\"", "", "rec4" });
> temp.add(new String[] { "", "rec6", "rec7", "rec8" }); for (String[]
> temp1 : temp) {
> printer.printRecord(temp1);
> }
> printer.close();
> } {code}
> In above sample I have used 'setQuoteMode(QuoteMode.NONE)'. However, if we do
> not set the escape character using 'setEscape('#')' then it would result in
> following exception.
> {code:java}
> java.lang.IllegalArgumentException: No quotes mode set but no escape
> character is set. {code}
> At first, I was wondering why I was getting this error. Then I looked into
> the source and figured out that _CSVFormat.printWithEscapes()_ method
> internaly using _getEscapeCharacter().charValue()_ method to print records.
>
> However, the error message which we are getting is sort of misleading. It
> implies that the code has not set any quote mode even though we set it.
> Simple and more meaningful exception message could be: "Quote mode set to
> NONE but no escape character is set".
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CSV-147) Better error message during faulty CSV record read
[
https://issues.apache.org/jira/browse/CSV-147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory updated CSV-147:
Summary: Better error message during faulty CSV record read (was: Better
error handling in CSV, see included code)
> Better error message during faulty CSV record read
> --
>
> Key: CSV-147
> URL: https://issues.apache.org/jira/browse/CSV-147
> Project: Commons CSV
> Issue Type: Improvement
> Components: Parser
>Affects Versions: 1.1
>Reporter: Steven Peterson
>Priority: Major
> Labels: easyfix
> Fix For: 1.10.1
>
> Attachments: csv-exceptionsupport.patch
>
> Original Estimate: 0.25h
> Remaining Estimate: 0.25h
>
> When parsing long files, and there is problem with parsing the data, it would
> be very useful to know the exact data that is bad when an exception is
> thrown. As CSVParser maintains a portion of the current record that was read
> when an exception is thrown (in the 'record' property), can we make this
> information public through something like this:
> {code:java}
> public String[] getLastRecordData() {
> return this.record.toArray(new String[this.record.size()]);
> }
> {code}
> With a method like this, it would be easy to pull in part of the data that
> was in the faulty record after an exception was thrown, aiding in cleaning up
> the data.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CSV-147) Better error handling in CSV, see included code
[
https://issues.apache.org/jira/browse/CSV-147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory resolved CSV-147.
-
Fix Version/s: 1.10.1
(was: Discussion)
Resolution: Fixed
> Better error handling in CSV, see included code
> ---
>
> Key: CSV-147
> URL: https://issues.apache.org/jira/browse/CSV-147
> Project: Commons CSV
> Issue Type: Improvement
> Components: Parser
>Affects Versions: 1.1
>Reporter: Steven Peterson
>Priority: Major
> Labels: easyfix
> Fix For: 1.10.1
>
> Attachments: csv-exceptionsupport.patch
>
> Original Estimate: 0.25h
> Remaining Estimate: 0.25h
>
> When parsing long files, and there is problem with parsing the data, it would
> be very useful to know the exact data that is bad when an exception is
> thrown. As CSVParser maintains a portion of the current record that was read
> when an exception is thrown (in the 'record' property), can we make this
> information public through something like this:
> {code:java}
> public String[] getLastRecordData() {
> return this.record.toArray(new String[this.record.size()]);
> }
> {code}
> With a method like this, it would be easy to pull in part of the data that
> was in the faulty record after an exception was thrown, aiding in cleaning up
> the data.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [commons-csv] garydgregory merged pull request #347: [CSV-147] Error message optimization during faulty CSV record read
garydgregory merged PR #347: URL: https://github.com/apache/commons-csv/pull/347 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (IMAGING-362) TIFF tags 0x111 and 0x117 have wrong descriptive names
[
https://issues.apache.org/jira/browse/IMAGING-362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17764633#comment-17764633
]
Gary Lucas commented on IMAGING-362:
Here's an example from ReadTagsAndImages.java
{code:java}
273 (0x111: PreviewImageStart): 2228, 2392, 2552, 2716, 2884, 3044, 3200,
3364, 3520, 3660
277 (0x115: SamplesPerPixel): 3 (1 Short)
278 (0x116: RowsPerStrip): 3 (1 Long)
279 (0x117: PreviewImageLength): 164, 160, 162, 165, 157, 155, 162, 156, 138,
172, 202, 22
{code}
> TIFF tags 0x111 and 0x117 have wrong descriptive names
> --
>
> Key: IMAGING-362
> URL: https://issues.apache.org/jira/browse/IMAGING-362
> Project: Commons Imaging
> Issue Type: Bug
> Components: Format: TIFF
>Affects Versions: 1.0-alpha2
>Reporter: Gary Lucas
>Priority: Minor
> Fix For: 1.0-alpha3
>
>
> The TIFF standard defines metadata elements using integer code values. For
> code values 0x111 and 0x117, Commons Imaging associates these with incorrect
> names "PreviewImageStart" and "PreviewImageLength". According to the
> specification "TIFF Revision 6.0 Final – June 3, 1992", the correct names for
> these are "StripOffsets" and "StripByteCounts". In fact, the word "preview"
> never even shows up in the TIFF specification.
> This should be an easy fix. No new test cases will be required, since these
> are descriptive elements only.
> The role of these two elements is to define the file position and length of
> data elements for TIFF files that are encoded as strips.
> One of the example programs in the Commons Imaging distribution (which is not
> compiled) is called ReadTagsAndImages.java. It can be used to dump TIFF tags.
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IMAGING-362) TIFF tags 0x111 and 0x117 have wrong descriptive names
Gary Lucas created IMAGING-362: -- Summary: TIFF tags 0x111 and 0x117 have wrong descriptive names Key: IMAGING-362 URL: https://issues.apache.org/jira/browse/IMAGING-362 Project: Commons Imaging Issue Type: Bug Components: Format: TIFF Affects Versions: 1.0-alpha2 Reporter: Gary Lucas Fix For: 1.0-alpha3 The TIFF standard defines metadata elements using integer code values. For code values 0x111 and 0x117, Commons Imaging associates these with incorrect names "PreviewImageStart" and "PreviewImageLength". According to the specification "TIFF Revision 6.0 Final – June 3, 1992", the correct names for these are "StripOffsets" and "StripByteCounts". In fact, the word "preview" never even shows up in the TIFF specification. This should be an easy fix. No new test cases will be required, since these are descriptive elements only. The role of these two elements is to define the file position and length of data elements for TIFF files that are encoded as strips. One of the example programs in the Commons Imaging distribution (which is not compiled) is called ReadTagsAndImages.java. It can be used to dump TIFF tags. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (BEANUTILS-563) Building from source release fails with a Maven error
[ https://issues.apache.org/jira/browse/BEANUTILS-563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17764548#comment-17764548 ] Michael Osipov commented on BEANUTILS-563: -- I use it as well, kudos to your work! > Building from source release fails with a Maven error > - > > Key: BEANUTILS-563 > URL: https://issues.apache.org/jira/browse/BEANUTILS-563 > Project: Commons BeanUtils > Issue Type: Bug > Components: Bean / Property Utils >Affects Versions: 1.9.4 >Reporter: Craig McClanahan >Priority: Major > > I downloaded the Commons Beanutils 1.9.4 release from > [https://dlcdn.apache.org//commons/beanutils/source/commons-beanutils-1.9.4-src.tar.gz] > And attempted to build it following the instructions at > [https://commons.apache.org/proper/commons-beanutils/building.html] > But encountered the following errors from Maven: > [*ERROR*] COMPILATION ERROR : > [*INFO*] - > [*ERROR*] Source option 6 is no longer supported. Use 7 or later. > [*ERROR*] Target option 6 is no longer supported. Use 7 or later. > [*INFO*] 2 errors > [*INFO*] - > > My Environment: > * Computer: MacBook Pro > * OS: Ventura 13.5.2 > * Java: 14.0.1 > * Maven: 3.6.3 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (BEANUTILS-563) Building from source release fails with a Maven error
[ https://issues.apache.org/jira/browse/BEANUTILS-563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17764517#comment-17764517 ] Craig McClanahan commented on BEANUTILS-563: I did better than that … I tried this with Java 14. But the POM says the source and target versions were Java 6, so it does not matter what later version I tried to use, or what anyone else who tries to build from the released source tries to use. You may or may not find it interesting that the original code for commons-beanutils was written by me, and extracted out of what is now Apache Struts, when it became obvious that dynamic access to properties of a JavaBean would be widely useful. That was 23 years ago. > Building from source release fails with a Maven error > - > > Key: BEANUTILS-563 > URL: https://issues.apache.org/jira/browse/BEANUTILS-563 > Project: Commons BeanUtils > Issue Type: Bug > Components: Bean / Property Utils >Affects Versions: 1.9.4 >Reporter: Craig McClanahan >Priority: Major > > I downloaded the Commons Beanutils 1.9.4 release from > [https://dlcdn.apache.org//commons/beanutils/source/commons-beanutils-1.9.4-src.tar.gz] > And attempted to build it following the instructions at > [https://commons.apache.org/proper/commons-beanutils/building.html] > But encountered the following errors from Maven: > [*ERROR*] COMPILATION ERROR : > [*INFO*] - > [*ERROR*] Source option 6 is no longer supported. Use 7 or later. > [*ERROR*] Target option 6 is no longer supported. Use 7 or later. > [*INFO*] 2 errors > [*INFO*] - > > My Environment: > * Computer: MacBook Pro > * OS: Ventura 13.5.2 > * Java: 14.0.1 > * Maven: 3.6.3 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
