I've removed the primitive APIs from trunk. This is seems too disruptive
toward a 1.0 at this point.
Gary
On Mon, Aug 5, 2013 at 1:18 AM, Adrian Crum
adrian.c...@sandglass-software.com wrote:
It might be best to suggest a facade that handles missing converters, null
or empty CSV fields,
The problem I'm seeing is, that this will again delay the 1.0 release of
CSV...
How about a compromise?
- Add conversion for basic data types to CSVRecord and finish 1.0
- Build a more sophisticated/configurable/pluggable wrapper that makes use
of what ever library for 1.x
I mean, look were we
Oh, a JDBC driver for csv files. Great idea! ;)
On Sunday, August 4, 2013, Benedikt Ritter wrote:
The problem I'm seeing is, that this will again delay the 1.0 release of
CSV...
How about a compromise?
- Add conversion for basic data types to CSVRecord and finish 1.0
- Build a more
On Sat, Aug 3, 2013 at 1:31 PM, James Carman ja...@carmanconsulting.comwrote:
+1. We need to eat our own dog food when it makes sense.
Would this be the proper way to do things with [convert]?
import org.apache.commons.convert.ConversionException;
import
It might be best to suggest a facade that handles missing converters,
null or empty CSV fields, etc. That's why I suggested leaving the type
conversion to the applications programmer - we can't know what the
developer wants to do in those cases.
-Adrian
On 8/4/2013 6:53 PM, Gary Gregory
Hi All:
I recently added these CSVRecord APIs: getBoolean(String), getInt(String),
getLong(String), getBigInteger(String).
Some people are OK with this, some consider this out of scope, some
consider it not necessary for 1.0, some -1, some are worried about feature
creep (default values,
If we only had a project called commons-convert! I'm sure Mr. Benson
could help us out using some of his Therian codebase (and his type
parameter prowess).
On Sat, Aug 3, 2013 at 11:36 AM, Gary Gregory garydgreg...@gmail.com wrote:
Hi All:
I recently added these CSVRecord APIs:
Have you considered recommending Commons Convert?
I agree that Java data type conversion is outside the scope of CSV.
-Adrian
On 8/3/2013 8:36 AM, Gary Gregory wrote:
Hi All:
I recently added these CSVRecord APIs: getBoolean(String), getInt(String),
getLong(String), getBigInteger(String).
On Sat, Aug 3, 2013 at 11:50 AM, Adrian Crum
adrian.c...@sandglass-software.com wrote:
Have you considered recommending Commons Convert?
No: it is unreleased. Are you willing to help polish it to 1.0?
Yes: I'd like to eat our own dog food.
Gary
I agree that Java data type conversion is
Inline...
On 8/3/2013 9:05 AM, Gary Gregory wrote:
On Sat, Aug 3, 2013 at 11:50 AM, Adrian Crum
adrian.c...@sandglass-software.com wrote:
Have you considered recommending Commons Convert?
No: it is unreleased. Are you willing to help polish it to 1.0?
Aside from a pending bug fix, the
Adrian, the conversions would be configurable. At least that's how I
envisioned it using existing BeanUtils functionality. Gary has a request
our to me to demo that.
On Aug 3, 2013 11:10 AM, Adrian Crum adrian.c...@sandglass-software.com
wrote:
Inline...
On 8/3/2013 9:05 AM, Gary Gregory
On Sat, Aug 3, 2013 at 12:05 PM, Gary Gregory garydgreg...@gmail.com wrote:
No: it is unreleased. Are you willing to help polish it to 1.0?
I'm willing!
The current API might be a bit verbose. We can figure out the bound
types at runtime to determine the source/target types. That would
Actually, I picture it like this: Commons CSV does not contain any
conversions, and data type conversions are left to the application
developer. We can recommend Commons Convert. The applications developer
is free to create any wrappers/facades necessary to connect the two.
-Adrian
On
I'll have to look into what Beanutils requires since it's been sometime I
last directly dealt with it. I think it comes with basic Java conversions
but everything can be configured as needed.
I did not know about Commons Convert. Why two commons project that do the
same thing?
Paul
On Sat, Aug
The OFBiz community wanted to spin off the conversion framework to a
separate project. I found the abandoned Commons Convert project and
moved the code there.
Someone suggested using Commons Convert for BeanUtils - so the
duplication can be eliminated.
-Adrian
On 8/3/2013 9:42 AM, Paul
On Sat, Aug 3, 2013 at 12:10 PM, Adrian Crum
adrian.c...@sandglass-software.com wrote:
Inline...
On 8/3/2013 9:05 AM, Gary Gregory wrote:
On Sat, Aug 3, 2013 at 11:50 AM, Adrian Crum
adrian.crum@sandglass-**software.com adrian.c...@sandglass-software.com
wrote:
Have you considered
On 8/3/2013 9:49 AM, Gary Gregory wrote:
On Sat, Aug 3, 2013 at 12:10 PM, Adrian Crum
adrian.c...@sandglass-software.com wrote:
Inline...
On 8/3/2013 9:05 AM, Gary Gregory wrote:
On Sat, Aug 3, 2013 at 11:50 AM, Adrian Crum
adrian.crum@sandglass-**software.com
On Sat, Aug 3, 2013 at 12:55 PM, Adrian Crum
adrian.c...@sandglass-software.com wrote:
On 8/3/2013 9:49 AM, Gary Gregory wrote:
On Sat, Aug 3, 2013 at 12:10 PM, Adrian Crum
adrian.crum@sandglass-**software.com adrian.c...@sandglass-software.com
wrote:
Inline...
On 8/3/2013 9:05 AM,
If Convert and BeanUtils do the same thing, I think Commons needs to figure
out how to solve this dilemma because duplicated functionality is usually
frowned upon here. For example, when Commons Lang began doing math, they
moved that to Commons Math (and the same thing happened for BeanUtils from
+1. We need to eat our own dog food when it makes sense. Our package
rename approach helps solve the jar hell issue, so adding dependencies
shouldn't be so frowned upon. Obviously if it's one little helper method
here and there we can copy the code if folks are really that averse to
I am working on getting the bug fixes committed today. I will also
include some more JavaDocs - hopefully that will help.
If anyone wants to improve things further, they are welcome to do so.
-Adrian
On 8/3/2013 9:17 AM, James Carman wrote:
On Sat, Aug 3, 2013 at 12:05 PM, Gary Gregory
21 matches
Mail list logo
