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:09 GMT
I totally agree with that Donald :), but now its been weeks discussing
the same subject and nothing changed. This is what I am talking about.

On Wed, Nov 4, 2009 at 4:32 PM, Donald Woods <dwoods@apache.org> wrote:
> Apache is built upon open collaboration within a community.
>
> Here, we have a significant code donation being offered, which would save us
> months or years in jump starting a JSR-303 implementation at Apache.
>  Therefore, I believe the only fair approach is one that allows the code
> contributor commit karma from day one, which would be he Podling route.
>
> We need to build a community around any JSR-303 implementation we create and
> having someone join from day one who has been working on JSR-303 since April
> 2008, would be a great asset to have on-board.
>
>
> -Donald
>
>
> Mohammad Nour El-Din wrote:
>>
>> Hi...
>>
>>   IMO, and sorry for saying that, now we've been transformed from
>> thinking about the project on how to get Roman involved in code
>> submission. IMO if this has no solution to be taken to get things up
>> and running fast enough so either Ron accepts that situation, or we
>> start doing it the way Nial started.
>>
>> On Wed, Nov 4, 2009 at 3:31 PM, Niall Pemberton
>> <niall.pemberton@gmail.com> 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?
>>>
>>> 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