Apache Commons › Commons - Dev

[validator] Direction of validator implementation based on JSR 303

43 messages

1 2 3

Niall Pemberton

[validator] Direction of validator implementation based on JSR 303

Reply Threaded

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: [hidden email]
For additional commands, e-mail: [hidden email]

Paul Benedict

Re: [validator] Direction of validator implementation based on JSR 303

Reply Threaded

+1

On Thu, Oct 22, 2009 at 9:33 PM, Niall Pemberton
<[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Henri Yandell

Re: [validator] Direction of validator implementation based on JSR 303

Reply Threaded

+!

On Thu, Oct 22, 2009 at 11:17 PM, Paul Benedict <[hidden email]> wrote:

> +1
>
> On Thu, Oct 22, 2009 at 9:33 PM, Niall Pemberton
> <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Simone Tripodi

Re: [validator] Direction of validator implementation based on JSR 303

Reply Threaded

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 <[hidden email]> wrote:

> +!
>
> On Thu, Oct 22, 2009 at 11:17 PM, Paul Benedict <[hidden email]> wrote:
>> +1
>>
>> On Thu, Oct 22, 2009 at 9:33 PM, Niall Pemberton
>> <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

--
http://www.google.com/profiles/simone.tripodi

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Niall Pemberton

Re: [validator] Direction of validator implementation based on JSR 303

Reply Threaded

On Fri, Oct 23, 2009 at 8:27 AM, Simone Tripodi
<[hidden email]> 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 <[hidden email]> wrote:
>> +!
>>
>> On Thu, Oct 22, 2009 at 11:17 PM, Paul Benedict <[hidden email]> wrote:
>>> +1
>>>
>>> On Thu, Oct 22, 2009 at 9:33 PM, Niall Pemberton
>>> <[hidden email]> 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: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
>
>
> --
> http://www.google.com/profiles/simone.tripodi
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Mohammad Nour El-Din

Re: [validator] Direction of validator implementation based on JSR 303

Reply Threaded

+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
<[hidden email]> wrote:

> On Fri, Oct 23, 2009 at 8:27 AM, Simone Tripodi
> <[hidden email]> 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 <[hidden email]> wrote:
>>> +!
>>>
>>> On Thu, Oct 22, 2009 at 11:17 PM, Paul Benedict <[hidden email]> wrote:
>>>> +1
>>>>
>>>> On Thu, Oct 22, 2009 at 9:33 PM, Niall Pemberton
>>>> <[hidden email]> 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: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>
>>
>>
>> --
>> http://www.google.com/profiles/simone.tripodi
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

--
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: [hidden email]
For additional commands, e-mail: [hidden email]

Simone Tripodi

Re: [validator] Direction of validator implementation based on JSR 303

Reply Threaded

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
<[hidden email]> 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
> <[hidden email]> wrote:
>> On Fri, Oct 23, 2009 at 8:27 AM, Simone Tripodi
>> <[hidden email]> 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 <[hidden email]> wrote:
>>>> +!
>>>>
>>>> On Thu, Oct 22, 2009 at 11:17 PM, Paul Benedict <[hidden email]> wrote:
>>>>> +1
>>>>>
>>>>> On Thu, Oct 22, 2009 at 9:33 PM, Niall Pemberton
>>>>> <[hidden email]> 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: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> http://www.google.com/profiles/simone.tripodi
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
>
>
> --
> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

Paul Benedict

Re: [validator] Direction of validator implementation based on JSR 303

Reply Threaded

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
<[hidden email]> 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
> <[hidden email]> 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
>> <[hidden email]> wrote:
>>> On Fri, Oct 23, 2009 at 8:27 AM, Simone Tripodi
>>> <[hidden email]> 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 <[hidden email]> wrote:
>>>>> +!
>>>>>
>>>>> On Thu, Oct 22, 2009 at 11:17 PM, Paul Benedict <[hidden email]> wrote:
>>>>>> +1
>>>>>>
>>>>>> On Thu, Oct 22, 2009 at 9:33 PM, Niall Pemberton
>>>>>> <[hidden email]> 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: [hidden email]
>>>>> For additional commands, e-mail: [hidden email]
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> http://www.google.com/profiles/simone.tripodi
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>
>>
>>
>> --
>> 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: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
>
>
> --
> http://www.google.com/profiles/simone.tripodi
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Matt Benson

Re: [validator] Direction of validator implementation based on JSR 303

Reply Threaded

In reply to this post by Mohammad Nour El-Din

+1

--- On Fri, 10/23/09, Mohammad Nour El-Din <[hidden email]> wrote:

> From: Mohammad Nour El-Din <[hidden email]>
> Subject: Re: [validator] Direction of validator implementation based on JSR 303
> To: "Commons Developers List" <[hidden email]>
> 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
> <[hidden email]>
> wrote:
> > On Fri, Oct 23, 2009 at 8:27 AM, Simone Tripodi
> > <[hidden email]>
> 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
> <[hidden email]>
> wrote:
> >>> +!
> >>>
> >>> On Thu, Oct 22, 2009 at 11:17 PM, Paul
> Benedict <[hidden email]>
> wrote:
> >>>> +1
> >>>>
> >>>> On Thu, Oct 22, 2009 at 9:33 PM, Niall
> Pemberton
> >>>> <[hidden email]>
> 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: [hidden email]
> >>> For additional commands, e-mail: [hidden email]
> >>>
> >>>
> >>
> >>
> >>
> >> --
> >> http://www.google.com/profiles/simone.tripodi
> >>
> >>
> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [hidden email]
> >> For additional commands, e-mail: [hidden email]
> >>
> >>
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
>
>
> --
> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Rahul Akolkar

Re: [validator] Direction of validator implementation based on JSR 303

Reply Threaded

In reply to this post by Niall Pemberton

On Thu, Oct 22, 2009 at 10:33 PM, Niall Pemberton
<[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

DWoods

Re: [validator] Direction of validator implementation based on JSR 303

Reply Threaded

In reply to this post by Niall Pemberton

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:

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Mohammad Nour El-Din

Re: [validator] Direction of validator implementation based on JSR 303

Reply Threaded

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 <[hidden email]> 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: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

DWoods

Re: [validator] Direction of validator implementation based on JSR 303

Reply Threaded

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 <[hidden email]> 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: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Phil Steitz

Re: [validator] Direction of validator implementation based on JSR 303

Reply Threaded

In reply to this post by DWoods

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: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Mohammad Nour El-Din

Re: [validator] Direction of validator implementation based on JSR 303

Reply Threaded

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 <[hidden email]> 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: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

Niall Pemberton

Re: [validator] Direction of validator implementation based on JSR 303

Reply Threaded

In reply to this post by DWoods

On Mon, Oct 26, 2009 at 2:06 PM, Donald Woods <[hidden email]> wrote:

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: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

DWoods

Re: [validator] Direction of validator implementation based on JSR 303

Reply Threaded

Niall Pemberton wrote:

> On Mon, Oct 26, 2009 at 2:06 PM, Donald Woods <[hidden email]> 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: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Niall Pemberton

Re: [validator] Direction of validator implementation based on JSR 303

Reply Threaded

On Tue, Oct 27, 2009 at 1:50 PM, Donald Woods <[hidden email]> wrote:

>
>
> Niall Pemberton wrote:
>>
>> On Mon, Oct 26, 2009 at 2:06 PM, Donald Woods <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Niall Pemberton

Re: [validator] Direction of validator implementation based on JSR 303

Reply Threaded

On Tue, Oct 27, 2009 at 1:54 PM, Niall Pemberton
<[hidden email]> wrote:

> On Tue, Oct 27, 2009 at 1:50 PM, Donald Woods <[hidden email]> wrote:
>>
>>
>> Niall Pemberton wrote:
>>>
>>> On Mon, Oct 26, 2009 at 2:06 PM, Donald Woods <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

DWoods

Re: [validator] Direction of validator implementation based on JSR 303

Reply Threaded

Niall Pemberton wrote:

> On Tue, Oct 27, 2009 at 1:54 PM, Niall Pemberton
> <[hidden email]> wrote:
>> On Tue, Oct 27, 2009 at 1:50 PM, Donald Woods <[hidden email]> wrote:
>>>
>>> Niall Pemberton wrote:
>>>> On Mon, Oct 26, 2009 at 2:06 PM, Donald Woods <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

1 2 3