Hi Rahul, very nice to meet you and thanks for your kind reply :) On Sun, Oct 4, 2009 at 2:01 AM, Rahul Akolkar <rahul.akol...@gmail.com> wrote: > On Sat, Oct 3, 2009 at 4:32 PM, Simone Tripodi <simone.trip...@gmail.com> > wrote: >> Hi all commons folks!!! >> I've been happily using the digester package since the 1.6 release, I >> found it very easy to use and absolutely one of the best way to parse >> quickly XML documents and mapping them to Java objects :) >> >> Even if using the XML rule declaration, or coding Digester rules, is >> absolutely very very easy, times ago I started implementing as a PoC >> [1], in my spare time, a facility tool able to create Digester >> instances automatically... taking inspiration by Google-Guice and >> JPA's annotations, I wonder: "why can't we generate the Digester's >> Rules through Java5 annotations?" > <snip/> > > May be about time :-) Annotations are probably a good idea for a > number of digester usecases. The competing viewpoint has been that > turning the digester "configuration" into a distributed definition of > the rules can hinder readability (and thus, understandability, > maintainability etc.). Seems best to leave that choice to users. >
Yes I totally agree, I didn't explicate very well, but my intention is providing a new package that could be used in combination with the existing ones and not totally replace old methodologies :P I already met a case where annotations weren't enough so I had to add, by programmatic way, missing rules. > >> What I realized in my mind was the >> phrase "Basically, the Digester package lets you configure an XML -> >> Java object mapping module, which triggers certain actions called >> rules whenever a particular pattern of nested XML elements is >> recognized." >> >> So, my idea is: simply given an Annotated Class, we wanted to inspect >> it, and extract all the needed to generate the rules - in this way, we >> could save time writing the rules manually and reduce the errors while >> binding properties and methods'name, arguments etc, etc. >> > <snip-provided-example/> >> >> and a special DigesterLoader is able to create Digester rules simply >> by analizing the ServletBean class: >> >> Digester digester = DigesterLoader.createDigester(ServletBean.class); >> >> And that's all! >> > <snap/> > > Cool :-) And given that a slew of classes may need such inspection, > providing means to scan a package (or two) makes sense as well. > > >> While publishing this work on the Web (already licensed under the >> Apache 2.0 License) I wonder whether or not the >> Apache Community might be interested on this... would this be of >> interested to the community? is there anybody else out there >> in the community worked on something similar? I would more than happy to >> collaborate and find a way to merge the work into a bigger project >> eventually. >> > <snip/> > > I can see this being useful. As you know, theres nothing along these > lines in SVN here. WRT collaboration and how things work around here, > please read this if you haven't already: > > http://www.apache.org/foundation/how-it-works.html > Thanks to remind me, I'll take a deeper look to have more clear these concepts!!! > >> I aim to achieve a mature version of the project quicker and better; and >> ultimately after submitting the proposal to the Commons Commettee as Digester >> extension we would like to find ways grow the work in an official module of >> the >> distribution or a sub-project. >> > <snap/> > > Makes sense, the digester project doesn't have sub-projects so first > impression is if it isn't too much code adding it straight to be > library may be an option. Otherwise, something like a multi-module > Maven2 build for digester may be another option. If you ever wanted to > consider that route of proposing the code for inclusion into Commons, > and if the larger Commons community showed interest and supported it, > the IP clearance process described here would need to be followed: > > http://incubator.apache.org/ip-clearance/index.html Thanks. That's foundamental, I'll read it more than once. > > This is for any code proposed for inclusion in that has been developed > outside the ASF repository. > Well, my original idea was providing a runtime annotation interpreter and a compiler, so I though about subprojects, but at this stage - I still haven't thought about how to realize the compiler :P - I'm confident that by adding just a new subpackage in the existing project is enough. > >> Last, I would personally be really happy to contribute to the ASF in any way >> and >> maintain the above work if necessary. >> > <snip/> > > Thanks for your interest and offer to contribute. Given that you > aren't a committer already AFAIK, this will be quite a slow process > and you will need to have a whole lot of patience :-) I may be able to > help, but my cycles are limited so you'll have to bear with an often > slow pace of progress. Ofcourse, if more folks are interested things > can always speed up with the involvement of other committers. > No I'm not an Apache committer, I already contributed to Apache Cocoon3 submitting patches so I'm already a little familiar with how the process works, the Cocoon3 guys are very nice people and helped me to understand :) > -Rahul > Thank you once again, I really hope to continue in receiving feedbacks!!! Best Regards Simone Tripodi >> >> [1] http://code.google.com/p/digester-annotations/ >> >> -- >> http://www.google.com/profiles/simone.tripodi >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- http://www.google.com/profiles/simone.tripodi --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
