commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simone Tripodi <simone.trip...@gmail.com>
Subject Re: [digester] extension annottaion proposal
Date Sun, 04 Oct 2009 09:47:45 GMT
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.akolkar@gmail.com> wrote:
> On Sat, Oct 3, 2009 at 4:32 PM, Simone Tripodi <simone.tripodi@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>



-- 
http://www.google.com/profiles/simone.tripodi

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message