You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Niall Pemberton <ni...@gmail.com> on 2009/10/23 04:33:34 UTC
[validator] Direction of validator implementation based on JSR 303
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
Re: [validator] Direction of validator implementation based on JSR
303
Posted by Rahul Akolkar <ra...@gmail.com>.
On Thu, Oct 22, 2009 at 10:33 PM, Niall Pemberton
<ni...@gmail.com> wrote:
<snip/>
>
> 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?
>
<snap/>
Sounds cool.
-Rahul
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [validator] Direction of validator implementation based on JSR
303
Posted by Mohammad Nour El-Din <no...@gmail.com>.
+1 on the proposal :)
On Wed, Nov 4, 2009 at 4:35 PM, Donald Woods <dw...@apache.org> wrote:
>
>
> Niall Pemberton wrote:
>>
>> On Mon, Nov 2, 2009 at 10:51 PM, Donald Woods <dw...@apache.org> wrote:
>>>
>>> Niall Pemberton wrote:
>>>>
>>>> On Tue, Oct 27, 2009 at 1:50 PM, Donald Woods <dw...@apache.org> wrote:
>>>>>
>>>>> Niall Pemberton wrote:
>>>>>>
>>>>>> On Mon, Oct 26, 2009 at 2:06 PM, Donald Woods <dw...@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
Re: [validator] Direction of validator implementation based on JSR
303
Posted by Donald Woods <dw...@apache.org>.
Niall Pemberton wrote:
> On Wed, Nov 4, 2009 at 3:35 PM, Niall Pemberton
> <ni...@gmail.com> wrote:
>> On Wed, Nov 4, 2009 at 2:35 PM, Donald Woods <dw...@apache.org> wrote:
>>>
>>> Niall Pemberton wrote:
>>>> On Mon, Nov 2, 2009 at 10:51 PM, Donald Woods <dw...@apache.org> wrote:
>>>>> Niall Pemberton wrote:
>>>>>> On Tue, Oct 27, 2009 at 1:50 PM, Donald Woods <dw...@apache.org> wrote:
>>>>>>> Niall Pemberton wrote:
>>>>>>>> On Mon, Oct 26, 2009 at 2:06 PM, Donald Woods <dw...@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/
>
> I've set up a skeleton proposal here:
>
> http://wiki.apache.org/incubator/ValidationProposal
>
> I'm going to start to flesh it out
Thanks! I'll start adding some details too.
-Donald
>
> Niall
>
>> 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).
>>
>> 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
Re: [validator] Direction of validator implementation based on JSR
303
Posted by Niall Pemberton <ni...@gmail.com>.
On Wed, Dec 2, 2009 at 2:39 PM, Kevan Miller <ke...@gmail.com> wrote:
>
> On Nov 20, 2009, at 2:51 PM, Donald Woods wrote:
>
>> Take a look at the proposal and feel free to edit and add any missing info....
>
> http://wiki.apache.org/incubator/ValidationProposal -- looks good to me. Has there been a vote by the Commons community to sponsor?
Yes, here:
http://markmail.org/message/m6a5hfdunoxkox6n
Niall
> --kevan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [validator] Direction of validator implementation based on JSR 303
Posted by Kevan Miller <ke...@gmail.com>.
On Nov 20, 2009, at 2:51 PM, Donald Woods wrote:
> Take a look at the proposal and feel free to edit and add any missing info....
http://wiki.apache.org/incubator/ValidationProposal -- looks good to me. Has there been a vote by the Commons community to sponsor?
--kevan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [validator] Direction of validator implementation based on JSR
303
Posted by Donald Woods <dw...@apache.org>.
Take a look at the proposal and feel free to edit and add any missing
info....
-Donald
Simone Tripodi wrote:
> HI guys,
> being a volunteer to help you on developing the new Validation
> framework, is there any way I can help you on completing the proposal?
> Please let me know! Have a nice weekend, best regards
> Simone
>
> On Wed, Nov 18, 2009 at 9:47 PM, Donald Woods <dw...@apache.org> wrote:
>> I'm sure we'll get a few more interested committers from Geronimo and
>> OpenJPA. Was just waiting until we had an initial proposal draft completed
>> before posting it to those dev lists. I'll go ahead and post to those lists
>> today and maybe we can target you starting a Commons vote in the next week
>> or two, as we can try to get the podling approved before the Dec. holiday
>> season begins.....
>>
>>
>> -Donald
>>
>>
>> Niall Pemberton wrote:
>>> On Wed, Nov 18, 2009 at 8:03 PM, Donald Woods <dw...@apache.org> wrote:
>>>> OK, I finished my first rounds of updates.
>>> If we want Apache Commons to be sponsor then we should hold a vote here
>>> first.
>>>
>>>> Looks like we just need to nail
>>>> down a champion and we can add more mentors once we propose it to the
>>>> incubator....
>>> Kevan offered to be Champion which sounds good to me.
>>>
>>> Also Simone Tripodi was interested in this and looks like hes already
>>> a prject member of agimatec-validation - so perhaps we should ping
>>> him. Anyone else you know that might be interested in helping as a
>>> committer?
>>>
>>> Niall
>>>
>>>> -Donald
>>>>
>>>>
>>>> Niall Pemberton wrote:
>>>>
>>>>>> Lets start a proposal on the incubator wiki:
>>>>>> http://wiki.apache.org/incubator/
>>>>> I've set up a skeleton proposal here:
>>>>>
>>>>> http://wiki.apache.org/incubator/ValidationProposal
>>>>>
>>>>> I'm going to start to flesh it out
>>>>>
>>>>> Niall
>>>>>
>>>>>> Theres a guide here:
>>>>>> http://incubator.apache.org/guides/proposal.html
>>>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
Re: [validator] Direction of validator implementation based on JSR
303
Posted by Simone Tripodi <si...@gmail.com>.
HI guys,
being a volunteer to help you on developing the new Validation
framework, is there any way I can help you on completing the proposal?
Please let me know! Have a nice weekend, best regards
Simone
On Wed, Nov 18, 2009 at 9:47 PM, Donald Woods <dw...@apache.org> wrote:
> I'm sure we'll get a few more interested committers from Geronimo and
> OpenJPA. Was just waiting until we had an initial proposal draft completed
> before posting it to those dev lists. I'll go ahead and post to those lists
> today and maybe we can target you starting a Commons vote in the next week
> or two, as we can try to get the podling approved before the Dec. holiday
> season begins.....
>
>
> -Donald
>
>
> Niall Pemberton wrote:
>>
>> On Wed, Nov 18, 2009 at 8:03 PM, Donald Woods <dw...@apache.org> wrote:
>>>
>>> OK, I finished my first rounds of updates.
>>
>> If we want Apache Commons to be sponsor then we should hold a vote here
>> first.
>>
>>> Looks like we just need to nail
>>> down a champion and we can add more mentors once we propose it to the
>>> incubator....
>>
>> Kevan offered to be Champion which sounds good to me.
>>
>> Also Simone Tripodi was interested in this and looks like hes already
>> a prject member of agimatec-validation - so perhaps we should ping
>> him. Anyone else you know that might be interested in helping as a
>> committer?
>>
>> Niall
>>
>>> -Donald
>>>
>>>
>>> Niall Pemberton wrote:
>>>
>>>>> Lets start a proposal on the incubator wiki:
>>>>> http://wiki.apache.org/incubator/
>>>>
>>>> I've set up a skeleton proposal here:
>>>>
>>>> http://wiki.apache.org/incubator/ValidationProposal
>>>>
>>>> I'm going to start to flesh it out
>>>>
>>>> Niall
>>>>
>>>>> Theres a guide here:
>>>>> http://incubator.apache.org/guides/proposal.html
>>>>>
>>> ---------------------------------------------------------------------
>>> 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
>
>
--
http://www.google.com/profiles/simone.tripodi
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [validator] Direction of validator implementation based on JSR
303
Posted by Donald Woods <dw...@apache.org>.
I'm sure we'll get a few more interested committers from Geronimo and
OpenJPA. Was just waiting until we had an initial proposal draft
completed before posting it to those dev lists. I'll go ahead and post
to those lists today and maybe we can target you starting a Commons vote
in the next week or two, as we can try to get the podling approved
before the Dec. holiday season begins.....
-Donald
Niall Pemberton wrote:
> On Wed, Nov 18, 2009 at 8:03 PM, Donald Woods <dw...@apache.org> wrote:
>> OK, I finished my first rounds of updates.
>
> If we want Apache Commons to be sponsor then we should hold a vote here first.
>
>> Looks like we just need to nail
>> down a champion and we can add more mentors once we propose it to the
>> incubator....
>
> Kevan offered to be Champion which sounds good to me.
>
> Also Simone Tripodi was interested in this and looks like hes already
> a prject member of agimatec-validation - so perhaps we should ping
> him. Anyone else you know that might be interested in helping as a
> committer?
>
> Niall
>
>> -Donald
>>
>>
>> Niall Pemberton wrote:
>>
>>>> Lets start a proposal on the incubator wiki:
>>>> http://wiki.apache.org/incubator/
>>> I've set up a skeleton proposal here:
>>>
>>> http://wiki.apache.org/incubator/ValidationProposal
>>>
>>> I'm going to start to flesh it out
>>>
>>> Niall
>>>
>>>> Theres a guide here:
>>>> http://incubator.apache.org/guides/proposal.html
>>>>
>> ---------------------------------------------------------------------
>> 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
Re: [validator] Direction of validator implementation based on JSR
303
Posted by Niall Pemberton <ni...@gmail.com>.
On Wed, Nov 18, 2009 at 8:03 PM, Donald Woods <dw...@apache.org> wrote:
> OK, I finished my first rounds of updates.
If we want Apache Commons to be sponsor then we should hold a vote here first.
> Looks like we just need to nail
> down a champion and we can add more mentors once we propose it to the
> incubator....
Kevan offered to be Champion which sounds good to me.
Also Simone Tripodi was interested in this and looks like hes already
a prject member of agimatec-validation - so perhaps we should ping
him. Anyone else you know that might be interested in helping as a
committer?
Niall
>
> -Donald
>
>
> Niall Pemberton wrote:
>
>>> Lets start a proposal on the incubator wiki:
>>> http://wiki.apache.org/incubator/
>>
>> I've set up a skeleton proposal here:
>>
>> http://wiki.apache.org/incubator/ValidationProposal
>>
>> I'm going to start to flesh it out
>>
>> Niall
>>
>>> Theres a guide here:
>>> http://incubator.apache.org/guides/proposal.html
>>>
>
> ---------------------------------------------------------------------
> 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
Re: [validator] Direction of validator implementation based on JSR
303
Posted by Donald Woods <dw...@apache.org>.
OK, I finished my first rounds of updates. Looks like we just need to
nail down a champion and we can add more mentors once we propose it to
the incubator....
-Donald
Niall Pemberton wrote:
>> Lets start a proposal on the incubator wiki:
>> http://wiki.apache.org/incubator/
>
> I've set up a skeleton proposal here:
>
> http://wiki.apache.org/incubator/ValidationProposal
>
> I'm going to start to flesh it out
>
> Niall
>
>> Theres a guide here:
>> http://incubator.apache.org/guides/proposal.html
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [validator] Direction of validator implementation based on JSR
303
Posted by Niall Pemberton <ni...@gmail.com>.
On Wed, Nov 4, 2009 at 3:35 PM, Niall Pemberton
<ni...@gmail.com> wrote:
> On Wed, Nov 4, 2009 at 2:35 PM, Donald Woods <dw...@apache.org> wrote:
>>
>>
>> Niall Pemberton wrote:
>>>
>>> On Mon, Nov 2, 2009 at 10:51 PM, Donald Woods <dw...@apache.org> wrote:
>>>>
>>>> Niall Pemberton wrote:
>>>>>
>>>>> On Tue, Oct 27, 2009 at 1:50 PM, Donald Woods <dw...@apache.org> wrote:
>>>>>>
>>>>>> Niall Pemberton wrote:
>>>>>>>
>>>>>>> On Mon, Oct 26, 2009 at 2:06 PM, Donald Woods <dw...@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/
I've set up a skeleton proposal here:
http://wiki.apache.org/incubator/ValidationProposal
I'm going to start to flesh it out
Niall
> 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).
>
> 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
Re: [validator] Direction of validator implementation based on JSR
303
Posted by Niall Pemberton <ni...@gmail.com>.
On Wed, Nov 18, 2009 at 7:46 PM, Kevan Miller <ke...@gmail.com> wrote:
> Apologies for chiming in late.
>
> From a Geronimo/EE 6 perspective, I'm definitely interested in seeing a 303 implementation at Apache. I'm not likely to have much time for implementation. However, if champions or mentors are needed, I'd be willing to help.
Great - I added you to the proposal - thanks
Niall
> On Nov 4, 2009, at 11:27 AM, Donald Woods wrote:
>
>> Niall Pemberton wrote:
>
> <snip>
>
>>> 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.
>
> Subversion is going to be using non-incubator mailing lists. So, there is some precedent. No harm in trying, IMO...
>
> --kevan
> ---------------------------------------------------------------------
> 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
Re: [validator] Direction of validator implementation based on JSR 303
Posted by Kevan Miller <ke...@gmail.com>.
Apologies for chiming in late.
From a Geronimo/EE 6 perspective, I'm definitely interested in seeing a 303 implementation at Apache. I'm not likely to have much time for implementation. However, if champions or mentors are needed, I'd be willing to help.
On Nov 4, 2009, at 11:27 AM, Donald Woods wrote:
> Niall Pemberton wrote:
<snip>
>> 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.
Subversion is going to be using non-incubator mailing lists. So, there is some precedent. No harm in trying, IMO...
--kevan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [validator] Direction of validator implementation based on JSR
303
Posted by Donald Woods <dw...@apache.org>.
Niall Pemberton wrote:
> On Wed, Nov 4, 2009 at 4:03 PM, Donald Woods <dw...@apache.org> wrote:
>>
>> Niall Pemberton wrote:
>>> On Wed, Nov 4, 2009 at 2:35 PM, Donald Woods <dw...@apache.org> wrote:
>>>> Niall Pemberton wrote:
>>>>> On Mon, Nov 2, 2009 at 10:51 PM, Donald Woods <dw...@apache.org> wrote:
>>>>>> Niall Pemberton wrote:
>>>>>>> On Tue, Oct 27, 2009 at 1:50 PM, Donald Woods <dw...@apache.org>
>>>>>>> wrote:
>>>>>>>> Niall Pemberton wrote:
>>>>>>>>> On Mon, Oct 26, 2009 at 2:06 PM, Donald Woods <dw...@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
Re: [validator] Direction of validator implementation based on JSR
303
Posted by Niall Pemberton <ni...@gmail.com>.
On Wed, Nov 4, 2009 at 4:03 PM, Donald Woods <dw...@apache.org> wrote:
>
>
> Niall Pemberton wrote:
>>
>> On Wed, Nov 4, 2009 at 2:35 PM, Donald Woods <dw...@apache.org> wrote:
>>>
>>> Niall Pemberton wrote:
>>>>
>>>> On Mon, Nov 2, 2009 at 10:51 PM, Donald Woods <dw...@apache.org> wrote:
>>>>>
>>>>> Niall Pemberton wrote:
>>>>>>
>>>>>> On Tue, Oct 27, 2009 at 1:50 PM, Donald Woods <dw...@apache.org>
>>>>>> wrote:
>>>>>>>
>>>>>>> Niall Pemberton wrote:
>>>>>>>>
>>>>>>>> On Mon, Oct 26, 2009 at 2:06 PM, Donald Woods <dw...@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
Re: [validator] Direction of validator implementation based on JSR
303
Posted by Donald Woods <dw...@apache.org>.
Niall Pemberton wrote:
> On Wed, Nov 4, 2009 at 2:35 PM, Donald Woods <dw...@apache.org> wrote:
>>
>> Niall Pemberton wrote:
>>> On Mon, Nov 2, 2009 at 10:51 PM, Donald Woods <dw...@apache.org> wrote:
>>>> Niall Pemberton wrote:
>>>>> On Tue, Oct 27, 2009 at 1:50 PM, Donald Woods <dw...@apache.org> wrote:
>>>>>> Niall Pemberton wrote:
>>>>>>> On Mon, Oct 26, 2009 at 2:06 PM, Donald Woods <dw...@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....
-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
Re: [validator] Direction of validator implementation based on JSR
303
Posted by Niall Pemberton <ni...@gmail.com>.
On Wed, Nov 4, 2009 at 2:35 PM, Donald Woods <dw...@apache.org> wrote:
>
>
> Niall Pemberton wrote:
>>
>> On Mon, Nov 2, 2009 at 10:51 PM, Donald Woods <dw...@apache.org> wrote:
>>>
>>> Niall Pemberton wrote:
>>>>
>>>> On Tue, Oct 27, 2009 at 1:50 PM, Donald Woods <dw...@apache.org> wrote:
>>>>>
>>>>> Niall Pemberton wrote:
>>>>>>
>>>>>> On Mon, Oct 26, 2009 at 2:06 PM, Donald Woods <dw...@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).
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
Re: [validator] Direction of validator implementation based on JSR
303
Posted by Donald Woods <dw...@apache.org>.
Niall Pemberton wrote:
> On Mon, Nov 2, 2009 at 10:51 PM, Donald Woods <dw...@apache.org> wrote:
>>
>> Niall Pemberton wrote:
>>> On Tue, Oct 27, 2009 at 1:50 PM, Donald Woods <dw...@apache.org> wrote:
>>>> Niall Pemberton wrote:
>>>>> On Mon, Oct 26, 2009 at 2:06 PM, Donald Woods <dw...@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
Re: [validator] Direction of validator implementation based on JSR
303
Posted by Mohammad Nour El-Din <no...@gmail.com>.
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 <dw...@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
>> <ni...@gmail.com> wrote:
>>>
>>> On Mon, Nov 2, 2009 at 10:51 PM, Donald Woods <dw...@apache.org> wrote:
>>>>
>>>> Niall Pemberton wrote:
>>>>>
>>>>> On Tue, Oct 27, 2009 at 1:50 PM, Donald Woods <dw...@apache.org>
>>>>> wrote:
>>>>>>
>>>>>> Niall Pemberton wrote:
>>>>>>>
>>>>>>> On Mon, Oct 26, 2009 at 2:06 PM, Donald Woods <dw...@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
Re: [validator] Direction of validator implementation based on JSR
303
Posted by Donald Woods <dw...@apache.org>.
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
> <ni...@gmail.com> wrote:
>> On Mon, Nov 2, 2009 at 10:51 PM, Donald Woods <dw...@apache.org> wrote:
>>>
>>> Niall Pemberton wrote:
>>>> On Tue, Oct 27, 2009 at 1:50 PM, Donald Woods <dw...@apache.org> wrote:
>>>>> Niall Pemberton wrote:
>>>>>> On Mon, Oct 26, 2009 at 2:06 PM, Donald Woods <dw...@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
Re: [validator] Direction of validator implementation based on JSR
303
Posted by Mohammad Nour El-Din <no...@gmail.com>.
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
<ni...@gmail.com> wrote:
> On Mon, Nov 2, 2009 at 10:51 PM, Donald Woods <dw...@apache.org> wrote:
>>
>>
>> Niall Pemberton wrote:
>>>
>>> On Tue, Oct 27, 2009 at 1:50 PM, Donald Woods <dw...@apache.org> wrote:
>>>>
>>>> Niall Pemberton wrote:
>>>>>
>>>>> On Mon, Oct 26, 2009 at 2:06 PM, Donald Woods <dw...@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
>
>
--
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
Re: [validator] Direction of validator implementation based on JSR
303
Posted by Niall Pemberton <ni...@gmail.com>.
On Mon, Nov 2, 2009 at 10:51 PM, Donald Woods <dw...@apache.org> wrote:
>
>
> Niall Pemberton wrote:
>>
>> On Tue, Oct 27, 2009 at 1:50 PM, Donald Woods <dw...@apache.org> wrote:
>>>
>>> Niall Pemberton wrote:
>>>>
>>>> On Mon, Oct 26, 2009 at 2:06 PM, Donald Woods <dw...@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
Re: [validator] Direction of validator implementation based on JSR
303
Posted by Mohammad Nour El-Din <no...@gmail.com>.
Seems not :(, wdyt should we go the way Niall started ?
On Tue, Nov 3, 2009 at 12:51 AM, Donald Woods <dw...@apache.org> wrote:
>
>
> Niall Pemberton wrote:
>>
>> On Tue, Oct 27, 2009 at 1:50 PM, Donald Woods <dw...@apache.org> wrote:
>>>
>>> Niall Pemberton wrote:
>>>>
>>>> On Mon, Oct 26, 2009 at 2:06 PM, Donald Woods <dw...@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?
>
> -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
Re: [validator] Direction of validator implementation based on JSR
303
Posted by Donald Woods <dw...@apache.org>.
Niall Pemberton wrote:
> On Tue, Oct 27, 2009 at 1:50 PM, Donald Woods <dw...@apache.org> wrote:
>>
>> Niall Pemberton wrote:
>>> On Mon, Oct 26, 2009 at 2:06 PM, Donald Woods <dw...@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?
-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
Re: [validator] Direction of validator implementation based on JSR
303
Posted by Donald Woods <dw...@apache.org>.
Niall Pemberton wrote:
> On Tue, Oct 27, 2009 at 1:54 PM, Niall Pemberton
> <ni...@gmail.com> wrote:
>> On Tue, Oct 27, 2009 at 1:50 PM, Donald Woods <dw...@apache.org> wrote:
>>>
>>> Niall Pemberton wrote:
>>>> On Mon, Oct 26, 2009 at 2:06 PM, Donald Woods <dw...@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.
>
> OK but either route it needs to be recorded.
OK, just forwarded it to secretary and legal-archive.
-Donald
>
> Niall
>
>>>>> 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.
>>
>> 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
Re: [validator] Direction of validator implementation based on JSR
303
Posted by Niall Pemberton <ni...@gmail.com>.
On Tue, Oct 27, 2009 at 1:54 PM, Niall Pemberton
<ni...@gmail.com> wrote:
> On Tue, Oct 27, 2009 at 1:50 PM, Donald Woods <dw...@apache.org> wrote:
>>
>>
>> Niall Pemberton wrote:
>>>
>>> On Mon, Oct 26, 2009 at 2:06 PM, Donald Woods <dw...@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.
OK but either route it needs to be recorded.
Niall
>>>> 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.
>
> 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
Re: [validator] Direction of validator implementation based on JSR
303
Posted by Niall Pemberton <ni...@gmail.com>.
On Tue, Oct 27, 2009 at 1:50 PM, Donald Woods <dw...@apache.org> wrote:
>
>
> Niall Pemberton wrote:
>>
>> On Mon, Oct 26, 2009 at 2:06 PM, Donald Woods <dw...@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.
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
Re: [validator] Direction of validator implementation based on JSR
303
Posted by Donald Woods <dw...@apache.org>.
Niall Pemberton wrote:
> On Mon, Oct 26, 2009 at 2:06 PM, Donald Woods <dw...@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.
Can you start a discussion on private@commons about accepting the
codebase and which method the community would like to follow?
-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
Re: [validator] Direction of validator implementation based on JSR
303
Posted by Niall Pemberton <ni...@gmail.com>.
On Mon, Oct 26, 2009 at 2:06 PM, Donald Woods <dw...@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?
> 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.
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
Re: [validator] Direction of validator implementation based on JSR
303
Posted by Donald Woods <dw...@apache.org>.
The amount of time to start over seems like a waste, given we have an
existing ASL 2.0 licensed codebase which is 75-80% done and wanting to
come over to the ASF....
-Donald
Mohammad Nour El-Din wrote:
> Hi Donald...
>
> If moving the code of Agimatic into ASF going to be problematic why
> not to start a clean room implementation as Niall suggested ?
>
> On Mon, Oct 26, 2009 at 4:06 PM, Donald Woods <dw...@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. 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. 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?
>>
>>
>> [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
Re: [validator] Direction of validator implementation based on JSR
303
Posted by Mohammad Nour El-Din <no...@gmail.com>.
Hi Donald...
If moving the code of Agimatic into ASF going to be problematic why
not to start a clean room implementation as Niall suggested ?
On Mon, Oct 26, 2009 at 4:06 PM, Donald Woods <dw...@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. 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. 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?
>
>
> [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
Re: [validator] Direction of validator implementation based on JSR
303
Posted by Mohammad Nour El-Din <no...@gmail.com>.
Hi Niall...
I think we need to know your comment on that as you are the one who
started the thread and the effort related to what we started to
discuss on this thread :).
On Tue, Oct 27, 2009 at 3:43 AM, Phil Steitz <ph...@gmail.com> wrote:
> Donald Woods wrote:
>>
> <snip/>
> 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?
>
> I am not familiar enough with the code to comment, but from a
> process standpoint, Roman could remove the copyright statements
> before submitting, if that is what he / Agimatec wanted to do. In
> any case, once granted, existing committers could work with the code
> and Roman could submit patches. We have done this several times in
> Commons: contributors who are not committers grant code, then earn
> merit in the normal way by submitting patches and contributing on
> the mailing lists.
>
> Phil
>>
>>
>> [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
>
>
--
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
Re: [validator] Direction of validator implementation based on JSR
303
Posted by Phil Steitz <ph...@gmail.com>.
Donald Woods wrote:
>
<snip/>
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?
I am not familiar enough with the code to comment, but from a
process standpoint, Roman could remove the copyright statements
before submitting, if that is what he / Agimatec wanted to do. In
any case, once granted, existing committers could work with the code
and Roman could submit patches. We have done this several times in
Commons: contributors who are not committers grant code, then earn
merit in the normal way by submitting patches and contributing on
the mailing lists.
Phil
>
>
> [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
Re: [validator] Direction of validator implementation based on JSR
303
Posted by Donald Woods <dw...@apache.org>.
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. 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. 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?
[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
Re: [validator] Direction of validator implementation based on JSR 303
Posted by Matt Benson <gu...@yahoo.com>.
+1
--- On Fri, 10/23/09, Mohammad Nour El-Din <no...@gmail.com> wrote:
> From: Mohammad Nour El-Din <no...@gmail.com>
> Subject: Re: [validator] Direction of validator implementation based on JSR 303
> To: "Commons Developers List" <de...@commons.apache.org>
> Date: Friday, October 23, 2009, 4:35 AM
> +1
>
> Actually this is even better to start from scratch. I am in
> Niall.
>
> On Fri, Oct 23, 2009 at 9:48 AM, Niall Pemberton
> <ni...@gmail.com>
> wrote:
> > On Fri, Oct 23, 2009 at 8:27 AM, Simone Tripodi
> > <si...@gmail.com>
> wrote:
> >> Hi guys,
> >> I don't have the rights to express votes but at
> least please let me
> >
> > Anyone can vote - it may end up we don't agree - but
> votes are appreciated.
> >
> >> say that sounds great, commons-validation has to
> be the proper home
> >> for JSR303, I'd like to contribute in this project
> since I already
> >> started studying the spec :)
> >
> > Great - I'm assuming you're not an existing ASF
> committer, so it'll
> > have to be patches via JIRA tickets:
> >
> > http://commons.apache.org/validator/issue-tracking.html
> >
> > Probably best to ping the list before starting work so
> that we don't
> > end up duplicating effort.
> >
> > Niall
> >
> >> All the best,
> >> Simone
> >>
> >>
> >> On Fri, Oct 23, 2009 at 8:58 AM, Henri Yandell
> <fl...@gmail.com>
> wrote:
> >>> +!
> >>>
> >>> On Thu, Oct 22, 2009 at 11:17 PM, Paul
> Benedict <pb...@apache.org>
> wrote:
> >>>> +1
> >>>>
> >>>> On Thu, Oct 22, 2009 at 9:33 PM, Niall
> Pemberton
> >>>> <ni...@gmail.com>
> 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.
> >>>
> >>>
> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>
> >>>
> >>
> >>
> >>
> >> --
> >> http://www.google.com/profiles/simone.tripodi
> >>
> >>
> ---------------------------------------------------------------------
> >> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [validator] Direction of validator implementation based on JSR
303
Posted by Paul Benedict <pb...@apache.org>.
Doesn't Commons Validator currently include JavaScript routines? I
think that's value that shouldn't be thrown away regardless of JSR-303
implementation.
Paul
On Fri, Oct 23, 2009 at 8:56 AM, Simone Tripodi
<si...@gmail.com> wrote:
> Hi Niall,
> thanks for your reply, that's my
>
> +1
>
> :) I'm not an Apache Committer but I already contributed to Cocoon3
> and just submitted my first patch to commons-digester, so I'm quite
> familiar to how things work here.
>
> Sure, I'll follow the list and take me in consideration!!
> All the best,
> Simone
>
> On Fri, Oct 23, 2009 at 11:35 AM, Mohammad Nour El-Din
> <no...@gmail.com> wrote:
>> +1
>>
>> Actually this is even better to start from scratch. I am in Niall.
>>
>> On Fri, Oct 23, 2009 at 9:48 AM, Niall Pemberton
>> <ni...@gmail.com> wrote:
>>> On Fri, Oct 23, 2009 at 8:27 AM, Simone Tripodi
>>> <si...@gmail.com> wrote:
>>>> Hi guys,
>>>> I don't have the rights to express votes but at least please let me
>>>
>>> Anyone can vote - it may end up we don't agree - but votes are appreciated.
>>>
>>>> say that sounds great, commons-validation has to be the proper home
>>>> for JSR303, I'd like to contribute in this project since I already
>>>> started studying the spec :)
>>>
>>> Great - I'm assuming you're not an existing ASF committer, so it'll
>>> have to be patches via JIRA tickets:
>>>
>>> http://commons.apache.org/validator/issue-tracking.html
>>>
>>> Probably best to ping the list before starting work so that we don't
>>> end up duplicating effort.
>>>
>>> Niall
>>>
>>>> All the best,
>>>> Simone
>>>>
>>>>
>>>> On Fri, Oct 23, 2009 at 8:58 AM, Henri Yandell <fl...@gmail.com> wrote:
>>>>> +!
>>>>>
>>>>> On Thu, Oct 22, 2009 at 11:17 PM, Paul Benedict <pb...@apache.org> wrote:
>>>>>> +1
>>>>>>
>>>>>> On Thu, Oct 22, 2009 at 9:33 PM, Niall Pemberton
>>>>>> <ni...@gmail.com> 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.
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> http://www.google.com/profiles/simone.tripodi
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>>
>>
>
>
>
> --
> http://www.google.com/profiles/simone.tripodi
>
> ---------------------------------------------------------------------
> 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
Re: [validator] Direction of validator implementation based on JSR
303
Posted by Simone Tripodi <si...@gmail.com>.
Hi Niall,
thanks for your reply, that's my
+1
:) I'm not an Apache Committer but I already contributed to Cocoon3
and just submitted my first patch to commons-digester, so I'm quite
familiar to how things work here.
Sure, I'll follow the list and take me in consideration!!
All the best,
Simone
On Fri, Oct 23, 2009 at 11:35 AM, Mohammad Nour El-Din
<no...@gmail.com> wrote:
> +1
>
> Actually this is even better to start from scratch. I am in Niall.
>
> On Fri, Oct 23, 2009 at 9:48 AM, Niall Pemberton
> <ni...@gmail.com> wrote:
>> On Fri, Oct 23, 2009 at 8:27 AM, Simone Tripodi
>> <si...@gmail.com> wrote:
>>> Hi guys,
>>> I don't have the rights to express votes but at least please let me
>>
>> Anyone can vote - it may end up we don't agree - but votes are appreciated.
>>
>>> say that sounds great, commons-validation has to be the proper home
>>> for JSR303, I'd like to contribute in this project since I already
>>> started studying the spec :)
>>
>> Great - I'm assuming you're not an existing ASF committer, so it'll
>> have to be patches via JIRA tickets:
>>
>> http://commons.apache.org/validator/issue-tracking.html
>>
>> Probably best to ping the list before starting work so that we don't
>> end up duplicating effort.
>>
>> Niall
>>
>>> All the best,
>>> Simone
>>>
>>>
>>> On Fri, Oct 23, 2009 at 8:58 AM, Henri Yandell <fl...@gmail.com> wrote:
>>>> +!
>>>>
>>>> On Thu, Oct 22, 2009 at 11:17 PM, Paul Benedict <pb...@apache.org> wrote:
>>>>> +1
>>>>>
>>>>> On Thu, Oct 22, 2009 at 9:33 PM, Niall Pemberton
>>>>> <ni...@gmail.com> 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.
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> http://www.google.com/profiles/simone.tripodi
>>>
>>> ---------------------------------------------------------------------
>>> 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
>
>
--
http://www.google.com/profiles/simone.tripodi
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [validator] Direction of validator implementation based on JSR
303
Posted by Mohammad Nour El-Din <no...@gmail.com>.
+1
Actually this is even better to start from scratch. I am in Niall.
On Fri, Oct 23, 2009 at 9:48 AM, Niall Pemberton
<ni...@gmail.com> wrote:
> On Fri, Oct 23, 2009 at 8:27 AM, Simone Tripodi
> <si...@gmail.com> wrote:
>> Hi guys,
>> I don't have the rights to express votes but at least please let me
>
> Anyone can vote - it may end up we don't agree - but votes are appreciated.
>
>> say that sounds great, commons-validation has to be the proper home
>> for JSR303, I'd like to contribute in this project since I already
>> started studying the spec :)
>
> Great - I'm assuming you're not an existing ASF committer, so it'll
> have to be patches via JIRA tickets:
>
> http://commons.apache.org/validator/issue-tracking.html
>
> Probably best to ping the list before starting work so that we don't
> end up duplicating effort.
>
> Niall
>
>> All the best,
>> Simone
>>
>>
>> On Fri, Oct 23, 2009 at 8:58 AM, Henri Yandell <fl...@gmail.com> wrote:
>>> +!
>>>
>>> On Thu, Oct 22, 2009 at 11:17 PM, Paul Benedict <pb...@apache.org> wrote:
>>>> +1
>>>>
>>>> On Thu, Oct 22, 2009 at 9:33 PM, Niall Pemberton
>>>> <ni...@gmail.com> 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.
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>>
>>
>> --
>> http://www.google.com/profiles/simone.tripodi
>>
>> ---------------------------------------------------------------------
>> 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
Re: [validator] Direction of validator implementation based on JSR
303
Posted by Niall Pemberton <ni...@gmail.com>.
On Fri, Oct 23, 2009 at 8:27 AM, Simone Tripodi
<si...@gmail.com> wrote:
> Hi guys,
> I don't have the rights to express votes but at least please let me
Anyone can vote - it may end up we don't agree - but votes are appreciated.
> say that sounds great, commons-validation has to be the proper home
> for JSR303, I'd like to contribute in this project since I already
> started studying the spec :)
Great - I'm assuming you're not an existing ASF committer, so it'll
have to be patches via JIRA tickets:
http://commons.apache.org/validator/issue-tracking.html
Probably best to ping the list before starting work so that we don't
end up duplicating effort.
Niall
> All the best,
> Simone
>
>
> On Fri, Oct 23, 2009 at 8:58 AM, Henri Yandell <fl...@gmail.com> wrote:
>> +!
>>
>> On Thu, Oct 22, 2009 at 11:17 PM, Paul Benedict <pb...@apache.org> wrote:
>>> +1
>>>
>>> On Thu, Oct 22, 2009 at 9:33 PM, Niall Pemberton
>>> <ni...@gmail.com> 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.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
>
> --
> http://www.google.com/profiles/simone.tripodi
>
> ---------------------------------------------------------------------
> 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
Re: [validator] Direction of validator implementation based on JSR
303
Posted by Simone Tripodi <si...@gmail.com>.
Hi guys,
I don't have the rights to express votes but at least please let me
say that sounds great, commons-validation has to be the proper home
for JSR303, I'd like to contribute in this project since I already
started studying the spec :)
All the best,
Simone
On Fri, Oct 23, 2009 at 8:58 AM, Henri Yandell <fl...@gmail.com> wrote:
> +!
>
> On Thu, Oct 22, 2009 at 11:17 PM, Paul Benedict <pb...@apache.org> wrote:
>> +1
>>
>> On Thu, Oct 22, 2009 at 9:33 PM, Niall Pemberton
>> <ni...@gmail.com> 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.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
http://www.google.com/profiles/simone.tripodi
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [validator] Direction of validator implementation based on JSR
303
Posted by Henri Yandell <fl...@gmail.com>.
+!
On Thu, Oct 22, 2009 at 11:17 PM, Paul Benedict <pb...@apache.org> wrote:
> +1
>
> On Thu, Oct 22, 2009 at 9:33 PM, Niall Pemberton
> <ni...@gmail.com> 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.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [validator] Direction of validator implementation based on JSR
303
Posted by Paul Benedict <pb...@apache.org>.
+1
On Thu, Oct 22, 2009 at 9:33 PM, Niall Pemberton
<ni...@gmail.com> 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