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 started. We wanted to create a small and easy to use library for parsing CSV files. What we are now talking about feels like a pedant to Springs JdbcTemplate, RowMapper framework for CSV files. Benedikt 2013/8/3 Adrian Crum <adrian.c...@sandglass-software.com> > 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 <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 >> streamline the API quite a bit. >> >> ------------------------------**------------------------------**--------- >> To unsubscribe, e-mail: >> dev-unsubscribe@commons.**apache.org<dev-unsubscr...@commons.apache.org> >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> > > ------------------------------**------------------------------**--------- > To unsubscribe, e-mail: > dev-unsubscribe@commons.**apache.org<dev-unsubscr...@commons.apache.org> > For additional commands, e-mail: dev-h...@commons.apache.org > > -- http://people.apache.org/~britter/ http://www.systemoutprintln.de/ http://twitter.com/BenediktRitter http://github.com/britter
