On Fri, Jun 10, 2011 at 2:43 AM, Simone Tripodi <simonetrip...@apache.org> wrote: > 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?
AFAIK, yes to both, because the code already exists out in the wild. By contrast, if you had simply started the code in the sandbox and written it there, no grant would be needed. :) Matt > Many thanks in advance, have a nice day!!! > Simo > > http://people.apache.org/~simonetripodi/ > http://www.99soft.org/ > > > > On Fri, Jun 10, 2011 at 9:30 AM, Stephen Colebourne > <scolebou...@joda.org> 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 <ralph.go...@dslextreme.com> 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 >>> https://svn.apache.org/repos/asf/logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/rgoers/log4j2-core/src/main/java/org/apache/logging/log4j/core/config/plugins/ResolverUtil.java. >>> It is used by >>> https://svn.apache.org/repos/asf/logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/rgoers/log4j2-core/src/main/java/org/apache/logging/log4j/core/config/plugins/PluginManager.java. >>> >>> Of course, I have no idea if these bear any relationship to what you have >>> done. >>> >>> Ralph >>> >>> >> >> --------------------------------------------------------------------- >> 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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
