On 6/10/11 12: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. +1 - start separately in the sandbox and see where it goes. > 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.
+1 here as well. I think it is a shame that [id] has never made it to a release. The GUID stuff that prevented it from becoming releasable is now obsolete. I would be +1 to either promoting it with aim to release minus the GUID stuff or pulling the useful stuff (some of it "back") into [lang]. I have had my eyes on some of the Tomcat code that generates session ids to adapt / incorporate into [id]. In any case, my +1 here means I will help with the code and/or promotion. Phil > 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
