Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (athena.apache.org: domain of nour.mohammad@gmail.com
 designates 209.85.218.224 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type:content-transfer-encoding;
        b=Wb1HFLBoE85IhXbzob2pHrk7QIcQcQjrEjuFZCixh8jMVOfwWhDbauZ2LalX0SfJXU
         9uPLpKZG/p7rpsLN/JNUu3Iuts+GgRbN1/lo1lDbWxiEOcJDAoQ8FqLQo57CjFE9xR1Q
         qhodreHHQoEw72eWF1AN//J2LIv0MxNg7EJps=
MIME-Version: 1.0
In-Reply-To: <55afdc850911040531o23fe46ccwc043d2a3d9c0603@mail.gmail.com>
References: <55afdc850910221933y2e6d8a12ncafb9dfb247e0922@mail.gmail.com>
	 <4AE5ACC9.8000506@apache.org>
	 <55afdc850910270603p96fd6bcx38e9c77bf1c4cd8f@mail.gmail.com>
	 <4AE6FAA3.2070606@apache.org>
	 <55afdc850910270654r1d288368xb32266f9ba14dbfc@mail.gmail.com>
	 <4AEF6266.7060505@apache.org>
	 <55afdc850911040531o23fe46ccwc043d2a3d9c0603@mail.gmail.com>
Date: Wed, 4 Nov 2009 15:55:35 +0200
Message-ID: <f321b69f0911040555l38136c2bx4cf34dab7690d8d2@mail.gmail.com>
Subject: Re: [validator] Direction of validator implementation based on JSR
	303
From: Mohammad Nour El-Din <nour.mohammad@gmail.com>
To: Commons Developers List <dev@commons.apache.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

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> wro=
te:
>>>>>>
>>>>>> Hi Nail. =A0I'm the one who created that copy of 1.4, so it's fine i=
f we
>>>>>> repurpose it, see VALIDATOR-279.
>>>>>>
>>>>>> As far as the API, we already have a clean room copy of the 1.0 GA A=
PI
>>>>>> 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, se=
e
>>>>>> 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 whic=
h
>>>>>> is
>>>>>> ASL
>>>>>> 2.0 licensed to bring it over to Apache.
>>>>>
>>>>> Cool :)
>>>>>
>>>>>> =A0I have a completed SGA from the
>>>>>> company (Agimatec Gmbh) that developed the code, but was working wit=
h
>>>>>> 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-projec=
t
>>>> route.
>>>>
>>>>>> =A0Currently, our thoughts were to
>>>>>> bring it in as a subproject to an existing TLP (like Commons, OpenJP=
A
>>>>>> 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, ...). =A0The only
>>>>>> complication,
>>>>>> is that we would need to =A0offer committership to Roman from Agimat=
ec as
>>>>>> soon
>>>>>> as the Incubator IP clearance is finished, as he would need to be th=
e
>>>>>> one
>>>>>> to
>>>>>> remove the existing Agimatec copyright statements. =A0Thoughts?
>>>>>
>>>>> 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 hav=
e
>>>>> 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. =A0The only complication=
 with
>>>> a
>>>> sub-project, is I'd need a Commons PMC member to work with me to submi=
t
>>>> 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-valid=
ation_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 Valida=
tor
>>>>>>> 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 eve=
n
>>>>>>> try. The "routines" package was refactored realtively recently(!) a=
nd
>>>>>>> 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 th=
ree
>>>>>>> separate modules composing of:
>>>>>>>
>>>>>>> =A0- The Bean Validation (JSR303) API - no dependencies
>>>>>>> =A0- Standalone Validation Routines (based on existing validator
>>>>>>> routines package) - no dependencies including Bean Validation API
>>>>>>> =A0- Validation Framework - JSR303 implementation (depends on two
>>>>>>> modules
>>>>>>> above)
>>>>>>>
>>>>>>> I have created an alternative branch in the Validator sandbox proje=
ct
>>>>>>> based on the above approach:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> http://svn.apache.org/viewvc/commons/sandbox/validator2/branches/al=
ternative/
>>>>>>>
>>>>>>> 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 i=
s
>>>>>>> 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/al=
ternative/validation-api/
>>>>>>> [2]
>>>>>>>
>>>>>>>
>>>>>>> http://svn.apache.org/viewvc/commons/sandbox/validator2/branches/al=
ternative/validation-routines/
>>>>>>> [3]
>>>>>>>
>>>>>>>
>>>>>>> http://svn.apache.org/viewvc/commons/sandbox/validator2/branches/al=
ternative/validation-framework/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>


--=20
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