commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niall Pemberton <niall.pember...@gmail.com>
Subject Re: [validator] Direction of validator implementation based on JSR 303
Date Wed, 04 Nov 2009 16:10:54 GMT
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?

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


Mime
View raw message