On Tue, Oct 27, 2009 at 1:50 PM, Donald Woods <dwo...@apache.org> wrote:
>
>
> Niall Pemberton wrote:
>>
>> On Mon, Oct 26, 2009 at 2:06 PM, Donald Woods <dwo...@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.
>
>>
>>>  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 priv...@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-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Reply via email to