Hi James! I like the idea, the concept reminds me how TestNG's DataProvider and GoogleGuice Providers. Looking forward to see it in action! Simo
http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Sat, Nov 5, 2011 at 3:48 PM, James Carman <ja...@carmanconsulting.com> wrote: > What if we introduce a @Converter annotation and any method that is > annotated with this annotation is automatically registered as a > converter? It's similar to what I've done in Metastopheles > (http://metastopheles.sourceforge.net/). > > On Fri, Nov 4, 2011 at 8:15 AM, 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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
