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:27:23 GMT


Niall Pemberton wrote:
> On Wed, Nov 4, 2009 at 4:03 PM, Donald Woods <dwoods@apache.org> wrote:
>>
>> Niall Pemberton 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/
>>>
>>> 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).
>>>
>> Yep, definitely need a vote, as the community needs to be behind this.
>> As far as mailing list and JIRA, each Podling gets its own mailing list
>> @incubator and a JIRA project as part of the infra setup.  Seems that we
>> would only use the existing Commons lists and JIRA if we went the
>> sub-project route and used the Incubator just for the IP clearance....
> 
> Its the normal route to have separate lists @incubator - but I don't
> see why it has to go that way. If Commons is the intended destination
> then it will make acceptance by Commons smoother since they will see
> the activity during incubation. Anyway, I'm not wedded to this idea
> but I would like to start with that basis - if there is a negative
> reaction either here or if/when it goes to general@incubator then we
> can revert to the usual model. Is your objection because you don't
> like it or because you don't think it would be allowed?
> 

No objection.  I just hadn't seen any other Podlings do it this way... 
It's worth a try.

-Donald

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