You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Simone Tripodi <si...@apache.org> on 2011/06/09 22:29:34 UTC
[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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] codebase looking for a place to be contributed to commons
Posted by Luc Maisonobe <Lu...@free.fr>.
Le 10/06/2011 04:07, Matt Benson a écrit :
> On Thu, Jun 9, 2011 at 8:40 PM, Gary Gregory<ga...@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 Tripodi<si...@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!!!
>>> 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-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] codebase looking for a place to be contributed to commons
Posted by Matt Benson <gu...@gmail.com>.
On Thu, Jun 9, 2011 at 8:40 PM, Gary Gregory <ga...@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 <si...@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!!!
>> 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-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] codebase looking for a place to be contributed to commons
Posted by Gary Gregory <ga...@gmail.com>.
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 <si...@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!!!
> 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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@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
Posted by James Carman <ja...@carmanconsulting.com>.
I like it too! I used Scannotation in my library that I wrote just
recently, but I would like to see something here in Commons that
handles classpath scanning. I think it should be its own component in
the sandbox.
On Thu, Jun 9, 2011 at 4:29 PM, Simone Tripodi <si...@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!!!
> 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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] codebase looking for a place to be contributed to commons
Posted by Olivier Lamy <ol...@apache.org>.
nice tool !
IMHO sounds a nice new component in commons.
2011/6/9 Simone Tripodi <si...@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
Olivier Lamy
http://twitter.com/olamy | http://www.linkedin.com/in/olamy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] codebase looking for a place to be contributed to commons
Posted by Simone Tripodi <si...@apache.org>.
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 <gu...@gmail.com> wrote:
> On Thu, Jun 9, 2011 at 3:29 PM, Simone Tripodi <si...@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-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] codebase looking for a place to be contributed to commons
Posted by Matt Benson <gu...@gmail.com>.
On Thu, Jun 9, 2011 at 3:29 PM, Simone Tripodi <si...@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] codebase looking for a place to be contributed to commons
Posted by Torsten Curdt <tc...@vafer.org>.
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 <si...@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 <tc...@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-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
http://www.yourdailygeekery.com
http://www.torstencurdt.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] codebase looking for a place to be contributed to commons
Posted by Simone Tripodi <si...@apache.org>.
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 <tc...@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] codebase looking for a place to be contributed to commons
Posted by Torsten Curdt <tc...@vafer.org>.
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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] codebase looking for a place to be contributed to commons
Posted by Matt Benson <gu...@gmail.com>.
On Fri, Jun 10, 2011 at 2:43 AM, Simone Tripodi
<si...@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
> <sc...@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 <ra...@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-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] codebase looking for a place to be contributed to commons
Posted by Simone Tripodi <si...@apache.org>.
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
<sc...@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 <ra...@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] codebase looking for a place to be contributed to commons
Posted by Simone Tripodi <si...@apache.org>.
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 <ph...@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 <ra...@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-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] codebase looking for a place to be contributed to commons
Posted by Phil Steitz <ph...@gmail.com>.
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 <ra...@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] codebase looking for a place to be contributed to commons
Posted by Jörg Schaible <jo...@scalaris.com>.
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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] codebase looking for a place to be contributed to commons
Posted by Stephen Colebourne <sc...@joda.org>.
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 <ra...@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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] codebase looking for a place to be contributed to commons
Posted by Ralph Goers <ra...@dslextreme.com>.
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