commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mohammad Nour El-Din <nour.moham...@gmail.com>
Subject Re: [validator] Direction of validator implementation based on JSR 303
Date Wed, 04 Nov 2009 15:29:59 GMT
+1 on the proposal :)

On Wed, Nov 4, 2009 at 4: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.
>
> -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
>
>



-- 
Thanks
- Mohammad Nour
- LinkedIn: http://www.linkedin.com/in/mnour
----
"Life is like riding a bicycle. To keep your balance you must keep moving"
- Albert Einstein

"Writing clean code is what you must do in order to call yourself a
professional. There is no reasonable excuse for doing anything less
than your best."
- Clean Code: A Handbook of Agile Software Craftsmanship

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message