I am interested on see Jame's code, a brach would work perfectly for me! Matt Benson has nice stuff too at his hands, it would be great having all of them merged in one project. Maybe one day [beanutils] will be the main [convert] consumer... :) Simo
http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Fri, Nov 4, 2011 at 1:15 PM, Adrian Crum <adrian.c...@sandglass-software.com> wrote: > Agreed. Please don't mis-interpret my replies - I'm not trying to "own" the > sandbox, I just want everyone to have a chance to play in it. > > The recent interest in Convert is great - I hope its popularity and > usefulness grows. I'm truly looking forward to more people getting involved. > > The current code base started out as a work I authored for the Apache Open > For Business Project (OFBiz). The converter framework was used for OFBiz's > scripting language. My initial work was built out and improved upon by an > excellent team of developers. When the converter framework was fairly > complete, someone suggested that OFBiz "spin off" the converter framework to > a separate library - so I brought it here to Commons. > > The code you see today is currently being used in an enterprise-class open > source ERP application. It is scalable and thread-safe. > > Commons Convert has not been "fed back" to the OFBiz project yet because it > is still in the sandbox. Until a decent sized community grows around it, the > OFBiz community will not be willing to switch over to it. I hope to see that > switch happen someday. > > -Adrian > > On 11/4/2011 11:33 AM, James Carman wrote: >> >> A branch would work just fine for that situation. Also, let's keep in mind >> that this component is in the sandbox >> On Nov 4, 2011 7:28 AM, "Adrian Crum"<adrian.c...@sandglass-software.com> >> wrote: >> >>> Not so that someone else can commit them, so that others can review them >>> and comment on them. >>> >>> -Adrian >>> >>> On 11/4/2011 11:25 AM, James Carman wrote: >>> >>>> If need be, I would just create a branch for my work. It would be silly >>>> for me to submit patches so that someone else would commit them >>>> On Nov 4, 2011 7:20 AM, "Adrian Crum"<adrian.crum@sandglass-** >>>> software.com<adrian.c...@sandglass-software.com>> >>>> wrote: >>>> >>>> From my perspective, it would be preferable to keep the community >>>>> >>>>> involved >>>>> in the design decisions. >>>>> >>>>> -Adrian >>>>> >>>>> On 11/4/2011 11:15 AM, James Carman wrote: >>>>> >>>>> I don't have to submit a patch. I am a commons committer >>>>>> >>>>>> On Nov 4, 2011 5:55 AM, "Adrian Crum"<adrian.crum@sandglass-** >>>>>> >>>>>> software.com<adrian.crum@**sandglass-software.com<adrian.c...@sandglass-software.com> >>>>>> wrote: >>>>>> >>>>>> The source and target classes are used by the Converter.canConvert >>>>>> >>>>>>> method. >>>>>>> The Converter.canConvert method is used by the Converter factory to >>>>>>> find >>>>>>> the correct converter. The reason parameterized types are not used in >>>>>>> this >>>>>>> scenario is so you can create converters that handle entire class >>>>>>> hierarchies. If you can think of a way to replace the Class >>>>>>> references >>>>>>> with >>>>>>> parameters, that would be great. Submit a patch and I will look it >>>>>>> over. >>>>>>> >>>>>>> You could submit a patch for your partially-completed ConverterChain >>>>>>> class >>>>>>> and maybe someone else will complete it. >>>>>>> >>>>>>> -Adrian >>>>>>> >>>>>>> >>>>>>> On 11/4/2011 2:19 AM, James Carman wrote: >>>>>>> >>>>>>> I was taking a look at the [convert] component because I have done >>>>>>> >>>>>>>> some work lately on some handy conversion classes. I'm struggling >>>>>>>> to >>>>>>>> understand why you'd need the getSourceClass() and getTargetClass() >>>>>>>> methods if you're using generics. >>>>>>>> >>>>>>>> >>>>>>>> Also, I've got a class that looks like this: >>>>>>>> >>>>>>>> public class ConverterChain<S,T> implements Converter<S,T> >>>>>>>> { >>>>>>>> public static<S> ConverterChain<S,S> from(Class<S> >>>>>>>> sourceType); >>>>>>>> public<N> ConverterChain<S,N> append(Converter<T,N> >>>>>>>> converter); >>>>>>>> ... >>>>>>>> } >>>>>>>> >>>>>>>> I'd like to contribute it, but in my library, I don't have all of >>>>>>>> those references to the class objects (source/target). I might >>>>>>>> check >>>>>>>> it in without the source/target stuff implemented. >>>>>>>> >>>>>>>> ------------------------------******--------------------------**--** >>>>>>>> --**--------- >>>>>>>> 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<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 >>> >>> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
