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 16:16:52 GMT


Niall Pemberton wrote:
> On Wed, Nov 4, 2009 at 3:35 PM, Niall Pemberton
> <niall.pemberton@gmail.com> wrote:
>> On Wed, Nov 4, 2009 at 2:35 PM, Donald Woods <dwoods@apache.org> wrote:
>>>
>>> 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.
>> Lets start a proposal on the incubator wiki:
>> http://wiki.apache.org/incubator/
> 
> I've set up a skeleton proposal here:
> 
> http://wiki.apache.org/incubator/ValidationProposal
> 
> I'm going to start to flesh it out

Thanks!  I'll start adding some details too.

-Donald

> 
> Niall
> 
>> Theres a guide here:
>> http://incubator.apache.org/guides/proposal.html
>>
>> Also I suggest we start a vote here (dev@commons) for Commons to be
>> the sponsoring PMC - but it might be better if we had the draft
>> proposal ready before calling a vote. One thought I had was (if
>> Commons votes to be the sponsoring PMC) that we could perhaps use the
>> commons mailing lists (commits@commons & dev@commons) and JIRA - that
>> way it would make it easier for the Commons community to follow
>> along/observe. Just because Commons sponsors though it doesn't mean
>> that it would automatically come here when ready to graduate (AIUI) -
>> which might be one reason to not use Commons resources (mailing list
>> and JIRA).
>>
>> Niall
>>
>>
>>> -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