Re: [DISCUSS] codebase looking for a place to be contributed to commons
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
Re: [DISCUSS] codebase looking for a place to be contributed to commons
Hi all guys, I just received the confirmation from Craig (secretary@a.o) that received the confirmation of my SoftwareGrant for Meiyo. I'll start a new VORE soon! Have a nice weekend, all the best! Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Sat, Jun 11, 2011 at 8:49 AM, Phil Steitz phil.ste...@gmail.com wrote: 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 - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [DISCUSS] codebase looking for a place to be contributed to commons
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
Re: [DISCUSS] codebase looking for a place to be contributed to commons
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
Re: [DISCUSS] codebase looking for a place to be contributed to commons
Hi Stephen, 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. I wanted to propose that also for some time now. +1 - Jörg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [DISCUSS] codebase looking for a place to be contributed to commons
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
Re: [DISCUSS] codebase looking for a place to be contributed to commons
Sorry, to rain the party here but AFAICS this project uses javasisst - which is LGPL/MPL. So I am not sure using this code is a viable option. It should be quite simple to replace that dependency (see https://github.com/tcurdt/jdependency ) though. cheers, Torsten -- http://www.yourdailygeekery.com http://www.torstencurdt.com - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [DISCUSS] codebase looking for a place to be contributed to commons
Hi Torsten!!! sorry for the silly question, but... which project uses Javassist? Because the Meiyo codebase is dependencies-less, take a look at the pom[1]... Thanks in advance, have a nice day!!! Simo [1] https://github.com/99soft/meiyo/blob/master/pom.xml http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Fri, Jun 10, 2011 at 10:13 AM, Torsten Curdt tcu...@vafer.org wrote: Sorry, to rain the party here but AFAICS this project uses javasisst - which is LGPL/MPL. So I am not sure using this code is a viable option. It should be quite simple to replace that dependency (see https://github.com/tcurdt/jdependency ) though. cheers, Torsten -- http://www.yourdailygeekery.com http://www.torstencurdt.com - 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
Re: [DISCUSS] codebase looking for a place to be contributed to commons
Bah ... Sorry. I somehow missed the beginning of the thread and thought this was about bringing Scannotation to Commons. Please, ignore that mail then :) On Fri, Jun 10, 2011 at 10:26, Simone Tripodi simonetrip...@apache.org wrote: Hi Torsten!!! sorry for the silly question, but... which project uses Javassist? Because the Meiyo codebase is dependencies-less, take a look at the pom[1]... Thanks in advance, have a nice day!!! Simo [1] https://github.com/99soft/meiyo/blob/master/pom.xml http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Fri, Jun 10, 2011 at 10:13 AM, Torsten Curdt tcu...@vafer.org wrote: Sorry, to rain the party here but AFAICS this project uses javasisst - which is LGPL/MPL. So I am not sure using this code is a viable option. It should be quite simple to replace that dependency (see https://github.com/tcurdt/jdependency ) though. cheers, Torsten -- http://www.yourdailygeekery.com http://www.torstencurdt.com - 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 -- http://www.yourdailygeekery.com http://www.torstencurdt.com - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [DISCUSS] codebase looking for a place to be contributed to commons
nice tool ! IMHO sounds a nice new component in commons. 2011/6/9 Simone Tripodi simonetrip...@apache.org: 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 -- Olivier Lamy http://twitter.com/olamy | http://www.linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[DISCUSS] codebase looking for a place to be contributed to commons
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
Re: [DISCUSS] codebase looking for a place to be contributed to commons
On Thu, Jun 9, 2011 at 3: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!!! Hi Simo, I like it. To me this looks like a separate component. It looks like a name like [scancp] would be clear of collisions. Matt P.S. What does meiyo mean? P.P.S. If you're going to keep using my configuration pattern, we're going to have to name it! ;) 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 - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [DISCUSS] codebase looking for a place to be contributed to commons
Hi Matt!!! I knew I could have attracted your attention :P Thanks for the suggestion. Do you think it is a worth for starting a vote about it? Have a nice day, all the best! Simo PS Meiyo is a Japanese word that means Honour, and it's one of the Bushi-Do seven virtues. PPS Indeed, you're totally right!!! components that apply it are proliferating, even Google Guice works in that way!!! Absolutely we have to have to find a name!!! http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Thu, Jun 9, 2011 at 10:45 PM, Matt Benson gudnabr...@gmail.com wrote: On Thu, Jun 9, 2011 at 3: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!!! Hi Simo, I like it. To me this looks like a separate component. It looks like a name like [scancp] would be clear of collisions. Matt P.S. What does meiyo mean? P.P.S. If you're going to keep using my configuration pattern, we're going to have to name it! ;) 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 - 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
Re: [DISCUSS] codebase looking for a place to be contributed to commons
Hi All: Classpath related functionality feels [lang]-y to me. My question: Why should it not be in [lang]? Thank you, Gary On Thu, Jun 9, 2011 at 4:29 PM, Simone Tripodi simonetrip...@apache.orgwrote: 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
Re: [DISCUSS] codebase looking for a place to be contributed to commons
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. Matt Thank you, Gary On Thu, Jun 9, 2011 at 4:29 PM, Simone Tripodi simonetrip...@apache.orgwrote: 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
Re: [DISCUSS] codebase looking for a place to be contributed to commons
Le 10/06/2011 04:07, Matt Benson a écrit : On Thu, Jun 9, 2011 at 8:40 PM, Gary Gregorygarydgreg...@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 Tripodisimonetrip...@apache.orgwrote: 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
Re: [DISCUSS] codebase looking for a place to be contributed to commons
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
