Le 09/06/2011 22:42, Simone Tripodi a écrit :
Hi all guys,
After some month of hard work on Digester3 on Sandbox[1] (and a
failing attempt), I'm here to open a vote to accept the new Digester
APIs be moved on proper /trunk.
The idea is to move the current /trunk in a DIGESTER_2_X branch, then
mov
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
Le 10/06/2011 04:07, Matt Benson a écrit :
On Thu, Jun 9, 2011 at 8:40 PM, Gary Gregory 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
On Thu, Jun 9, 2011 at 8:40 PM, Gary Gregory 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, 201
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 wrote:
> Hi all guys,
> before start working on Digester3 I experimented on GitHub, taking
> inspiration from Google Guice A
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 wrote:
> Hi all guys,
> before st
+1
On Jun 9, 2011 4:43 PM, "Simone Tripodi" wrote:
> Hi all guys,
> After some month of hard work on Digester3 on Sandbox[1] (and a
> failing attempt), I'm here to open a vote to accept the new Digester
> APIs be moved on proper /trunk.
> The idea is to move the current /trunk in a DIGESTER_2_X br
Hi Jochen!!!
thanks for your interest, I can reply to all of your questions: new
Digester APIs have been created branching the old ones, polishing
them, removed @Deprecated methods, and rewritten Annotations/XMLRules
internals, in order to be a natural extension of the new Rules binder.
SO:
> Is t
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
I am asking because of a recent case in ws: Is the new branch expected
to be binary upwards compatible or not?
If it is: Is there a clirr report or something similar?
If it is not: Does it change Java package name and Maven groupId
and/or artifactId?
Thanks,
Jochen
On Thu, Jun 9, 2011 at 10:4
On Thu, Jun 9, 2011 at 3:42 PM, Simone Tripodi wrote:
> Hi all guys,
> After some month of hard work on Digester3 on Sandbox[1] (and a
> failing attempt), I'm here to open a vote to accept the new Digester
> APIs be moved on proper /trunk.
> The idea is to move the current /trunk in a DIGESTER_2_X
On Thu, Jun 9, 2011 at 3: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 wi
Hi all guys,
After some month of hard work on Digester3 on Sandbox[1] (and a
failing attempt), I'm here to open a vote to accept the new Digester
APIs be moved on proper /trunk.
The idea is to move the current /trunk in a DIGESTER_2_X branch, then
move the Sandbox on current proper /trunk
The vote
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 in
On 6/9/11 9:05 AM, Mark Thomas wrote:
> On 09/06/2011 15:48, Gary Gregory wrote:
>> Hi All:
>>
>> I would like to understand the requirements better:
>>
>> - Is this for pool1 and/or pool2? It seems like a big change for pool1 that
>> should be in a 1.6 (not 1.5.x)
> pool2. No plans for this change
On 09/06/2011 15:48, Gary Gregory wrote:
> Hi All:
>
> I would like to understand the requirements better:
>
> - Is this for pool1 and/or pool2? It seems like a big change for pool1 that
> should be in a 1.6 (not 1.5.x)
pool2. No plans for this change in pool1.
> - Do we have real user stories
On 09/06/2011 14:50, sebb wrote:
> On 9 June 2011 14:41, Mark Thomas wrote:
>> On 09/06/2011 10:01, Julien Aymé wrote:
>>> 2011/6/9 Mark Thomas :
On 09/06/2011 04:39, Phil Steitz wrote:
> Code in trunk now does not work when distinct pooled instances are
> equal - i.e., if a factory p
Hi All:
I would like to understand the requirements better:
- Is this for pool1 and/or pool2? It seems like a big change for pool1 that
should be in a 1.6 (not 1.5.x)
- Do we have real user stories for this new req? Or is this a theoretical
nicety?
Thank you,
Gary
On Thu, Jun 9, 2011 at 9:50 AM
Oops, sorry.
Resent.
On 9 June 2011 14:53, Simone Tripodi wrote:
> Hi Seb,
> wrong ML?
> Simo
>
> http://people.apache.org/~simonetripodi/
> http://www.99soft.org/
>
>
>
> On Thu, Jun 9, 2011 at 3:38 PM, sebb wrote:
>> I was just looking through the poms for MINA.
>>
>> It looks as though only
Hi Seb,
wrong ML?
Simo
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Thu, Jun 9, 2011 at 3:38 PM, sebb wrote:
> I was just looking through the poms for MINA.
>
> It looks as though only the parent POM and mina-integration-xbean
> have a description.
>
> It would be helpfu
On 9 June 2011 14:41, Mark Thomas wrote:
> On 09/06/2011 10:01, Julien Aymé wrote:
>> 2011/6/9 Mark Thomas :
>>> On 09/06/2011 04:39, Phil Steitz wrote:
Code in trunk now does not work when distinct pooled instances are
equal - i.e., if a factory produces instances A and B and
A.equ
On 09/06/2011 10:01, Julien Aymé wrote:
> 2011/6/9 Mark Thomas :
>> On 09/06/2011 04:39, Phil Steitz wrote:
>>> Code in trunk now does not work when distinct pooled instances are
>>> equal - i.e., if a factory produces instances A and B and
>>> A.equals(B), this causes problems. I think this situ
I was just looking through the poms for MINA.
It looks as though only the parent POM and mina-integration-xbean
have a description.
It would be helpful to have descriptions in the other modules too.
Also, the parent description is:
Apache MINA is a network application framework which helps use
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at gene...@gump.apache.org.
Project commons-proxy-test has an issue affecting its community integration.
This
2011/6/9 Mark Thomas :
> On 09/06/2011 04:39, Phil Steitz wrote:
>> Code in trunk now does not work when distinct pooled instances are
>> equal - i.e., if a factory produces instances A and B and
>> A.equals(B), this causes problems. I think this situation should
>> be allowed - i.e. it is an una
On 09/06/2011 04:39, Phil Steitz wrote:
> Code in trunk now does not work when distinct pooled instances are
> equal - i.e., if a factory produces instances A and B and
> A.equals(B), this causes problems. I think this situation should
> be allowed - i.e. it is an unacceptable restriction to put
26 matches
Mail list logo
