On Sep 28, 2010, at 11:40 AM, Donald Woods wrote:

> Hi Matt, looks like you've been making a lot of progress with this.
> 

Yeah, I'm using this in $work on a mean deadline.  :)

> Any updates on the release schedule for the new commons-lang3?

:(  Perhaps I need to make a little noise there.

> 
> Also how is commons-proxy2-stub being used in bval-jsr303d?

I created proxy2-stub to have a typesafe way of creating Annotation proxies, 
and went ahead and designed that on top of a more generic proxy stubbing 
mechanism.  As I have mentioned here and there the approach is inspired by 
Mockito's stubbing mechanisms.  I believe I first brought proxy2-stub into 
bval-jsr303d for convenience in creating unit tests:  especially considering 
that the domain explictly IS dynamic constraints, it seemed appropriate.  
proxy2-stub became more of an optional dependency I suppose (and I'll mark it 
as such) when I began using it in the ConstraintAppender implementation for the 
dynamic Values and Values.Labeled constraints I baked into bval-jsr303d as a 
verification of the adequacy of the ConstraintAppender interface.

>  Is the
> dynamic api prototype support, which could remain in sandbox after we
> pull the commons-lang3 updates over into trunk?
> 

I had a little trouble parsing that--I think you're asking could the dynamic 
stuff remain behind "on probation" in the sandbox after integrating the lang3 
changes to the other modules.  I don't see why not--there should be no 
dependency on bval-jsr303d from any of the other modules.

-Matt

> 
> -Donald
> 
> 
> On 8/6/10 11:29 AM, Matt Benson wrote:
>> All:
>>  I have been experimenting with some of the type-related code in bval-core 
>> and bval-jsr303.  As I mentioned before, I am using commons-lang3's 
>> TypeUtils class for this work, and as I don't feel like doing weird 
>> temporary-copying things, I am thinking of creating a branch for 
>> experimentation that permits SNAPSHOT dependencies so that I can get my 
>> ideas committed someplace, particularly because some of them might bear 
>> discussion.  Does anyone have a preference on what I name this branch?  I 
>> don't really want to name it anything specific to my own name or anything 
>> like that, because I have no intention of discouraging others from working 
>> in this branch.  This is only necessary to keep lang3's release schedule 
>> from becoming a blocker.
>> 
>> Thanks for listening,
>> Matt

Reply via email to