commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simone Tripodi <>
Subject Re: [DISCUSS] codebase looking for a place to be contributed to commons
Date Fri, 10 Jun 2011 07:43:12 GMT
Hi all guys,
thanks for your interest!!! I think that joining our efforts we could
deliver yet another interesting apache-commons feature :)

@Ralph: I had a look at your stuff and, indeed, yours and mine have a
lot in common!!! Times should be now mature enough to generalize that
concepts and provide a unique, apache-commons solution.

@Stephen: I recently maintained Discovery but as far as I can
remember, there's no ClassPath scanning resolution. Anyway, sounds
that Discovery would be a good place where contributing the ClassPath
scanner... or not?

OTOH, the class/annotation scanner could be contributed in Lang... thoughts?

By the way, if you think it has to be a separate component, I could
start importing in Sanbox, for me it's fine as well!!

Just a question: do I have to send the Software Grant, before we start
working on it? And we should open a vote, right?
Many thanks in advance, have a nice day!!!

On Fri, Jun 10, 2011 at 9:30 AM, Stephen Colebourne
<> wrote:
> I've used scannotation before, which is reasonably well known I
> believe, but could probably be improved on. I think with multiple
> versions at Apache, it is a perfect concept for commons. I would check
> out [discovery] first to see if that has a similar goal.
> I'd set it up separately to [lang] first, to see how big it is. It
> feels a little frameworky, but may be suitable for inclusion.
> I also think that we should look to include ideas from the old [id]
> project into [lang], as [id] is never going to be released.
> Stephen
> On 10 June 2011 06:19, Ralph Goers <> wrote:
>> On Jun 9, 2011, at 1:29 PM, Simone Tripodi 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.
>> I accomplished this in the work I've been doing on Log4J 2.0 by borrowing on some
code I found somewhere else at Apache. You can see it at
It is used by
>> Of course, I have no idea if these bear any relationship to what you have done.
>> Ralph
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message