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 Lang).
If Convert is to be released, I think BeanUtils should get some refactoring for a 2.0 release. They should harmonize but not duplicate functionality. Paul On Sat, Aug 3, 2013 at 11:58 AM, Gary Gregory <garydgreg...@gmail.com>wrote: > 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, Gary Gregory wrote: > >>> > >>> On Sat, Aug 3, 2013 at 11:50 AM, Adrian Crum < > >>>> adrian.crum@sandglass-**softwa**re.com <http://software.com> < > >>>> adrian.crum@sandglass-**software.com< > 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 code is complete. The project has > been > >>> used by Apache OFBiz for years, so it is proven and stable. So, I don't > >>> know what additional steps are required to polish it. > >>> > >> > >> There's no user manual or FAQ, the Javadoc is thin. How do you get > >> started? > >> > > > > > > I will try to build out the docs a little more. I think I need karma to > > edit the Convert Wiki - adrianc. > > > > The docs should be in SVN IMO, just like most components. > > Gary > > > > > > > > > >> More below. > >> > >> > >> Having an official release would be wonderful. > >>> > >>> > >>> > >>> > >>> Yes: I'd like to eat our own dog food. > >>>> > >>>> Gary > >>>> > >>>> I agree that Java data type conversion is outside the scope of CSV. > >>>> > >>>>> What about a CSVRecord wrapper that delegates to [convert]? > >>>>> > >>>> What would that look like? From my experience, hard-coding conversions > >>> is > >>> not scalable. If an application needs to convert a CSV field to a > custom > >>> type Foo, how will the wrapper accommodate that? > >>> > >>> It would not for now. This is just about primitives or basic JRE types > >> like > >> Number and Date (Calendar). > >> > >> Gary > >> > >> > >> > >>> > >>> Gary > >>>> > >>>> > >>>> -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). > >>>>>> > >>>>>> 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, Date, List, and so on), some think > >>>>>> the > >>>>>> Javadoc should be clearer. > >>>>>> > >>>>>> At the very least I think we should document how to access or > convert > >>>>>> typed > >>>>>> values. We could: > >>>>>> > >>>>>> - Document the new APIs, or remove them AND: > >>>>>> - Document how to use another Commons API > >>>>>> - Document how to use another (non Commons) API > >>>>>> - Document how to do it all yourself > >>>>>> - Create a CSVRecrord wrapper class that contains all the APIs where > >>>>>> the > >>>>>> implementation may or may not delegate to another Commons API. > >>>>>> > >>>>>> No matter what, it's pretty obvious that this conversion code is > going > >>>>>> to > >>>>>> exist somewhere, in the user's app, in [csv] or someplace else. > >>>>>> > >>>>>> We should make a plan such that if we do not provide this feature in > >>>>>> 1.0, > >>>>>> we have a roadmap for our users. > >>>>>> > >>>>>> Gary > >>>>>> > >>>>>> > >>>>>> ------------------------------******--------------------------** > >>>>>> --** > >>>>>> > >>>>> --**--------- > >>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.****apac**he.org< > >>>>> http://apache.org**> > >>>>> <dev-unsubscribe@**commons.**apache.org <http://commons.apache.org>< > >>>>> 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.**apac**he.org< > http://apache.org> > >>> <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 > > > > > > > -- > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org > Java Persistence with Hibernate, Second Edition< > http://www.manning.com/bauer3/> > JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> > Spring Batch in Action <http://www.manning.com/templier/> > Blog: http://garygregory.wordpress.com > Home: http://garygregory.com/ > Tweet! http://twitter.com/GaryGregory > -- Cheers, Paul
