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, 02 Nov 2009 22:51:18 GMT

Niall Pemberton wrote:
> On Tue, Oct 27, 2009 at 1:50 PM, Donald Woods <> wrote:
>> Niall Pemberton wrote:
>>> On Mon, Oct 26, 2009 at 2: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.
>>> Cool :)
>>>>  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.
>>> Has the SGA been recorded at the ASF?
>> No, as I was waiting to see if we were going the Podling or sub-project
>> route.
>>>>  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?
>>> If we have an SGA from the Agimatec then I think anyone can remove
>>> their copyright statements from the source code. However its not nice
>>> IMO to take someones code and then expect them(Roman) to start
>>> submitting patches and not give them access. If we did this in the
>>> Commons Sandbox, then all the existing ASF committers can have access
>>> straight away - but I think its unlikely that the Commons PMC will
>>> grant Roman access from day one (I can ask though). If that is the
>>> case then it would be better to do it as an incubator podling. We have
>>> done that recently when commons accepted Sanselan from the incubator
>>> and graduating should be relatively easy since Commons's requirements
>>> for a component to be part of "proper" are usually 1) is it ready to
>>> release and 2) does it have 3+ committers.
>> Either a Podling or sub-project works for me.  The only complication with a
>> sub-project, is I'd need a Commons PMC member to work with me to submit the
>> initial Agimatec code snapshot, IP clearance form and SGA to the Incubator
>> for me.
> I can do that.
>> Can you start a discussion on private@commons about accepting the codebase
>> and which method the community would like to follow?
> Already done.

Any updates on this?


> Niall
>> -Donald
>>> Niall
>>>> [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:

View raw message