Le 10/06/2011 04:07, Matt Benson a écrit :
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.

Either in lang or as a separate component, it seems a good idea to me.

Luc


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



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

Reply via email to