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 Wed, 04 Nov 2009 14:35:32 GMT


Niall Pemberton wrote:
> On Mon, Nov 2, 2009 at 10:51 PM, Donald Woods <dwoods@apache.org> wrote:
>>
>> Niall Pemberton 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.
>>>>
>>>>>>  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?
> 
> Apologies for the delay in responding. I asked for opinions from the
> PMC specifically on whether we could give access to the Sandbox to
> someone who wasn't an ASF committer and didn't have a prior history of
> contribution. Most of the PMC has been silent on this and the response
> I did get was mixed (i.e. both for and against) so even if it was
> possible to get a majority vote, I am not comfortable pushing for this
> approach since I believe it would be divisive for Commons.
> 
> This means that if we go the Commons Sandbox route, then Roman would
> be left needing to submit patches to his own work until he'd earn't
> enough Karma to be voted in. Personally I don't think that would be a
> great situation unless he is completely happy doing that. So probably
> the best approach would be to go the Incubator podling route.
> 
> WDYT?

Yep, the Podling route seems the best solution (see my other reply to 
Mohammad for thoughts of why....)

Do you want me to start putting together a Proposal?  Figure we can use 
the Validator sandbox to collaborate on it till it's ready for submission.

-Donald


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