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!!! 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
