+1

On Thu, Oct 22, 2009 at 9:33 PM, Niall Pemberton
<niall.pember...@gmail.com> 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-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

Reply via email to