commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mohammad Nour El-Din <>
Subject Re: [validator] Direction of validator implementation based on JSR 303
Date Mon, 26 Oct 2009 15:29:12 GMT
Hi Donald...

   If moving the code of Agimatic into ASF going to be problematic why
not to start a clean room implementation as Niall suggested ?

On Mon, Oct 26, 2009 at 4:06 PM, Donald Woods <> wrote:
> 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?
> [1]
> [2]
> -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:
>> 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:

- Mohammad Nour
- LinkedIn:
"Life is like riding a bicycle. To keep your balance you must keep moving"
- Albert Einstein

"Writing clean code is what you must do in order to call yourself a
professional. There is no reasonable excuse for doing anything less
than your best."
- Clean Code: A Handbook of Agile Software Craftsmanship

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

View raw message