On Thu, Jun 9, 2011 at 8:40 PM, Gary Gregory <garydgreg...@gmail.com> wrote: > Hi All: > > Classpath related functionality feels [lang]-y to me. > > My question: Why should it not be in [lang]?
To me the codebase just feels like it has good boundaries and its own style. Matt > > Thank you, > Gary > > On Thu, Jun 9, 2011 at 4:29 PM, Simone Tripodi > <simonetrip...@apache.org>wrote: > >> Hi all guys, >> before start working on Digester3 I experimented on GitHub, taking >> inspiration from Google Guice APIs, embedded EDSLs in configuration >> classess to solve 2 different kind of problems: >> >> * ClassPath scanning[1]: declare with fluent APIs a class path >> scanner, filering classes users are interested in via fluent logic >> language, and declaring actions have to be performed, once interested >> classes have found. We already discussed about that idea time ago, but >> it has been improved; >> >> * Class scanning[2]: Java users often create framework/libraries >> based on Java5 MetaData Annotations interpreted at runtime, the >> pattern they usually have to apply is: given a class, visiting all the >> class inheritance hierarchy, and getting fields/constructors/methods >> for each class; once found an (AnnotatedElement, Annotation) pair, >> they have to perform an action. >> So, the implemented classes aim to reduce the boilerplate and >> redundant code simply by declaring actions that have to be performed >> once the pairs (AnnotatedElement, Annotation) are found. >> >> My proposals are: >> >> * contributing that codebase, even separately, to existing commons >> components, but which ones is not yet clear; >> >> or >> >> * donating the code as a separate component directly to Sandbox, >> finalizing it then moving eventually to Proper once ready. >> >> WDYT? Please let me know, have a nice day!!! >> Simo >> >> [1] http://s.apache.org/Ecu >> [2] http://s.apache.org/cEf >> >> http://people.apache.org/~simonetripodi/ >> http://www.99soft.org/ >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> > > > -- > Thank you, > Gary > > http://garygregory.wordpress.com/ > http://garygregory.com/ > http://people.apache.org/~ggregory/ > http://twitter.com/GaryGregory > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
