commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <phil.ste...@gmail.com>
Subject Re: [validator] Direction of validator implementation based on JSR 303
Date Tue, 27 Oct 2009 01:43:17 GMT
Donald Woods wrote:
> 
<snip/>
  The only complication, is that we would need to
>  offer committership to Roman from Agimatec as soon as the Incubator IP
> clearance is finished, as he would need to be the one to remove the
> existing Agimatec copyright statements.  Thoughts?

I am not familiar enough with the code to comment, but from a
process standpoint, Roman could remove the copyright statements
before submitting, if that is what he / Agimatec wanted to do.  In
any case, once granted, existing committers could work with the code
and Roman could submit patches.  We have done this several times in
Commons:  contributors who are not committers grant code, then earn
merit in the normal way by submitting patches and contributing on
the mailing lists.

Phil
> 
> 
> [1]
> https://svn.apache.org/repos/asf/geronimo/specs/trunk/geronimo-validation_1.0_spec
> 
> 
> [2] http://code.google.com/p/agimatec-validation/
> 
> 
> -Donald
> 
> 
> Niall Pemberton wrote:
>> The current trunk in the validator2 sandbox is a copy of the Validator
>> 1.4 code from "commons proper" - but I think we should dump all the
>> existing validator framework code and just retain the "routines"
>> package. Trying to maintain any sort of compatibility with the
>> existing validator framework would be alot more work and code and
>> create a real mess IMO and I think it would be better to not to even
>> try. The "routines" package was refactored realtively recently(!) and
>> can stand on its own.
>>
>> So I would like to propose the following direction for a Validator2
>> based on the Bean Validation Framework(JSR 303) - a project with three
>> separate modules composing of:
>>
>>   - The Bean Validation (JSR303) API - no dependencies
>>   - Standalone Validation Routines (based on existing validator
>> routines package) - no dependencies including Bean Validation API
>>   - Validation Framework - JSR303 implementation (depends on two
>> modules above)
>>
>> I have created an alternative branch in the Validator sandbox project
>> based on the above approach:
>>
>> http://svn.apache.org/viewvc/commons/sandbox/validator2/branches/alternative/
>>
>>
>> I have created a "clean room" implementation of the Bean Validation
>> API[1] which (hopefully) is complete except for JavaDocs. The only
>> real functionality is in javax.validation.Validation - the rest are
>> annotations, interfaces and exceptions. I have also copied the
>> "routines" package into a standalone module[2]. So the next thing is
>> to start the actual framework implementation module.
>>
>> How does this sound as an approach?
>>
>> Niall
>>
>> [1]
>> http://svn.apache.org/viewvc/commons/sandbox/validator2/branches/alternative/validation-api/
>>
>> [2]
>> http://svn.apache.org/viewvc/commons/sandbox/validator2/branches/alternative/validation-routines/
>>
>> [3]
>> http://svn.apache.org/viewvc/commons/sandbox/validator2/branches/alternative/validation-framework/
>>
>>
>> ---------------------------------------------------------------------
>> 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


Mime
View raw message