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,
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 wro
On Sat, Aug 3, 2013 at 1:31 PM, James Carman wrote:
> +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 org.apache.commons.convert.Converters;
public class CSVRecordC
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 mo
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 s
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 wrote
+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
dependenci
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
L
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 >
>> wrote:
>>
>> Inline...
>>>
>>>
>>> On 8/3/2013 9:05 AM, Gary Gregor
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 >
wrote:
Have you cons
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 >
>> wrote:
>>
>> Have you considered recommending Commo
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 Bene
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, Au
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 8/3/201
On Sat, Aug 3, 2013 at 12:05 PM, Gary Gregory 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
streamline the API quite
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"
wrote:
> Inline...
>
> On 8/3/2013 9:05 AM, Gary Gregory wrote:
>
>> On Sat, Aug 3, 2013 at
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 c
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
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).
So
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 wrote:
> Hi All:
>
> I recently added these CSVRecord APIs: getBoolean(String), getInt(String)
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, Calendar
21 matches
Mail list logo
