commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Donald Woods <>
Subject Re: [validator] Direction of validator implementation based on JSR 303
Date Mon, 26 Oct 2009 14:06:01 GMT
Hi Nail.  I'm the one who created that copy of 1.4, so it's fine if we 
repurpose it, see VALIDATOR-279.

As far as the API, we already have a clean room copy of the 1.0 GA API 
created over in the Apache Geronimo Specs subproject [1], with the other 
Java EE spec APIs we ship, so I'd be -1 on creating another copy, see 
VALIDATOR-274 for history.

As far as the provider implementation, I've been working with the 
Agimatec-Validation project [2] currently hosted on Google Code which is 
ASL 2.0 licensed to bring it over to Apache.  I have a completed SGA 
from the company (Agimatec Gmbh) that developed the code, but was 
working with some other ASF members on how we should bring the code into 
the ASF, so guess it's time to start discussing that here.  Currently, 
our thoughts were to bring it in as a subproject to an existing TLP 
(like Commons, OpenJPA or Geronimo) and not create a new Incubator 
Podling, since we have committers from multiple projects interested in 
working on a JSR-303 implementation (Geronimo, OpenJPA, MyFaces, 
OpenEJB, Commons, ...).  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?




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:
> 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]
> [2]
> [3]
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message