commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Donald Woods <dwo...@apache.org>
Subject Re: [validator] Direction of validator implementation based on JSR 303
Date Tue, 27 Oct 2009 19:36:22 GMT


Niall Pemberton wrote:
> On Tue, Oct 27, 2009 at 1:54 PM, Niall Pemberton
> <niall.pemberton@gmail.com> wrote:
>> On Tue, Oct 27, 2009 at 1:50 PM, Donald Woods <dwoods@apache.org> wrote:
>>>
>>> Niall Pemberton wrote:
>>>> On Mon, Oct 26, 2009 at 2:06 PM, Donald Woods <dwoods@apache.org> 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.
> 
> OK but either route it needs to be recorded.


OK, just forwarded it to secretary and legal-archive.


-Donald


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


Mime
View raw message