Re: [RESULT] [VOTE] [PROPOSAL] Validation incubator for JSR-303 Bean Validation
I've uploaded the incoming agimatec-validation source contribution to my home directory on people - /home/dwoods/agimatec-validation-0.9.6-src.tar.gz -Donald On 3/1/10 10:20 PM, Donald Woods wrote: The vote passes with the following +1 votes: Craig Russell, Alan Cabrera, Luciano Resende, Matthias Wessendorf, Jean-Frederic Clere, Martijn Dashorst, Mark Struberg, Kevan Miller, James Carman, Niall Pemberton, Bill Stoddard Voting 0 or no vote specified: Nick Kew (recended his initial -1 vote on the name) There were no standing -1 votes. Non-binding +1 votes: Francis De Brabandere, Mohammad Nour El-Din, Gurkan Erdogdu The requested resources in the proposal have been updated to use BVAL to better reflect the project's intention and I'll attach the results email to the proposal for history. Thanks, Donald Woods On 2/23/10 10:57 AM, Donald Woods wrote: Given the lack of response on the proposal and the push from our champion to get moving :-), I'll assume lazy consensus and call a vote. I would like to present for a vote the following proposal to be sponsored by the Incubator PMC for a new Validation podling. The goal is to build a community around delivering a JSR-303 Bean Validation implementation based on a new incoming codebase from Agimatec GmbH. The proposal is available on the wiki at and included below: http://wiki.apache.org/incubator/ValidationProposal [] +1 to accept Validation into the Incubator [] 0 don't care [] -1 object and reason why. Thanks, Donald Woods Proposal text from the wiki Validation Abstract The Validation project will deliver an implementation of the Bean Validation Specification (JSR303) Proposal The initial Validation codebase will use the Agimatec Validation source, which is an implementation of the Bean Validation Specification (JSR303). Although the destination of the Validation podling is not fixed, the idea is that it will graduate to Apache Commons and replace the existing Validator 1.x component as a new 2.0 codebase. Background Agimatec Validation has been developed by Agimatec Gmbh and is about 90% complete towards implementing the JSR303 specification. The Agimatec-Validation project is currently hosted on Google Code and is ASL 2.0 licensed. Agimatec has no intention to complete or maintain the implementation but has given the lead developer permission to continue working on the project on his own time. A number of existing Apache projects (Geronimo, OpenJPA, MyFaces, OpenEJB, Commons) are interested in an implementation of the Bean Validation specification and Donald Woods suggested adopting the Agimatec Validation code rather than starting from scratch. Rationale There is currently no Apache project focused on providing a JSR-303 implementation. The existing Commons Validator 1.x project codebase does not include support for Java 5 annotations and predates the JSR-303 specification effort. By using the Agimatec-Validation code, we can bootstrap the effort to create a Validator 2 release and focus on polishing/enhancing the code, certification activities and integration and support of other Apache projects. Current Status Agimatec Validation and is about 95% complete towards implementing the JSR303 specification. An SGA for the Agimatec Validation has been received and on file from Agimatec Gmbh. Meritocracy As a majority of the initial project members are existing ASF committers, we recognize the desirability of running the project as a meritocracy. We are eager to engage other members of the community and operate to the standard of meritocracy that Apache emphasizes; we believe this is the most effective method of growing our community and enabling widespread adoption. Community Even though the reference implementation for the JSR-303 Bean Validation specification is licensed under ASL 2.0, it is not being developed with meritocracy in mind, as the release process is controlled by the JBoss division of Red Hat to meet their own product needs. Validation aims to build a community of developers interested in the definition and delivery of a JSR-303 compliant runtime, which can be reused as a common component by a number of different projects (like Geronimo, OpenJPA, MyFaces, ) By maintaining independence of the target runtime, it is our intention to build the broadest possible community of developers. Core Developers The lead developer from the Agimatec Validation project will be joined by a number of committers from existing ASF projects. Alignment The purpose of Validation is to develop a certified implementation of JSR-303. Some components may be developed and delivered by other Apache projects, like: * Bean Validation 1.0 spec API - Apache Geronimo Specs subproject * JSF2 integration - MyFaces ExtVal components Known Risks The current JSR-303 portions of the
Re: [RESULT] [VOTE] [PROPOSAL] Validation incubator for JSR-303 Bean Validation
On Wed, Mar 3, 2010 at 7:38 PM, Donald Woods dwo...@apache.org wrote: I've uploaded the incoming agimatec-validation source contribution to my home directory on people - /home/dwoods/agimatec-validation-0.9.6-src.tar.gz -Donald I have created a main JIRA with various subtasks to o handle Validation podling infrastructure setup. https://issues.apache.org/jira/browse/INFRA-2526 -- Luciano Resende http://people.apache.org/~lresende http://twitter.com/lresende1975 http://lresende.blogspot.com/ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] [PROPOSAL] Validation incubator for JSR-303 Bean Validation
On Feb 26, 2010, at 7:18 PM, Nick Kew wrote: On 26 Feb 2010, at 19:01, Kevan Miller wrote: On Feb 23, 2010, at 4:03 PM, Nick Kew wrote: On Tue, 23 Feb 2010 12:51:35 -0500 Donald Woods dwo...@apache.org wrote: I'm open to suggestions BeanValidation, OpenValidation, Validera, ... Any of those work for me, though OpenValidation has a hint of the same problem. BeanValidation might be ideal, and scans better than, say JSR303-Validation :) Most likely outcome -- this ends up becoming Commons Validator version 2. If project decides to go TLP, the BeanValidation would be good with me. I would certainly expect this to be resolved by the community for graduation. Sounds OK to me. Since it looks as if my previous reply got lost in the ether, let me confirm, I'm happy to withdraw my -1 on the basis that the issue has been raised and will be resolved before or during incubation. Thanks Nick. Donald -- you called the vote. Can you close it, also? --kevan - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] [PROPOSAL] Validation incubator for JSR-303 Bean Validation
Already done, unless there is something I missed... http://old.nabble.com/-VOTE---PROPOSAL--Validation-incubator-for-JSR-303-Bean-Validation-to27705544.html#a27751839 -Donald On 3/2/10 3:46 PM, Kevan Miller wrote: On Feb 26, 2010, at 7:18 PM, Nick Kew wrote: On 26 Feb 2010, at 19:01, Kevan Miller wrote: On Feb 23, 2010, at 4:03 PM, Nick Kew wrote: On Tue, 23 Feb 2010 12:51:35 -0500 Donald Woods dwo...@apache.org wrote: I'm open to suggestions BeanValidation, OpenValidation, Validera, ... Any of those work for me, though OpenValidation has a hint of the same problem. BeanValidation might be ideal, and scans better than, say JSR303-Validation :) Most likely outcome -- this ends up becoming Commons Validator version 2. If project decides to go TLP, the BeanValidation would be good with me. I would certainly expect this to be resolved by the community for graduation. Sounds OK to me. Since it looks as if my previous reply got lost in the ether, let me confirm, I'm happy to withdraw my -1 on the basis that the issue has been raised and will be resolved before or during incubation. Thanks Nick. Donald -- you called the vote. Can you close it, also? --kevan - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] [PROPOSAL] Validation incubator for JSR-303 Bean Validation
Thanks Matthias and I've added you as a mentor. -Donald On 2/23/10 10:22 PM, Matthias Wessendorf wrote: +1 to accept Validation into the Incubator afterwards we still can see where it actually ends up however I for sure want to see this at Apache. If you guys need a champion or mentor, count me in !! -M On Tue, Feb 23, 2010 at 11:45 PM, Donald Woods dwo...@apache.org wrote: We're leaving the TLP/sub-project decision till graduation... -Donald On 2/23/10 5:36 PM, Brett Porter wrote: As I understand it from the proposal, they intend to be Apache Commons Validation. On 24/02/2010, at 4:19 AM, Nick Kew wrote: On Tue, 23 Feb 2010 10:57:33 -0500 Donald Woods dwo...@apache.org wrote: Given the lack of response on the proposal and the push from our champion to get moving :-), I'll assume lazy consensus and call a vote. I would like to present for a vote the following proposal to be sponsored by the Incubator PMC for a new Validation podling. The goal is to build a community around delivering a JSR-303 Bean Validation implementation based on a new incoming codebase from Agimatec GmbH. The proposal is available on the wiki at and included below: http://wiki.apache.org/incubator/ValidationProposal -1 to a project that could end up being called Apache Validation or just Validation. That's too big/general a word for a project name. No objection under a changed name. I'd suggest adding an adjective to indicate what is being validated. -- Nick Kew - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[RESULT] [VOTE] [PROPOSAL] Validation incubator for JSR-303 Bean Validation
The vote passes with the following +1 votes: Craig Russell, Alan Cabrera, Luciano Resende, Matthias Wessendorf, Jean-Frederic Clere, Martijn Dashorst, Mark Struberg, Kevan Miller, James Carman, Niall Pemberton, Bill Stoddard Voting 0 or no vote specified: Nick Kew (recended his initial -1 vote on the name) There were no standing -1 votes. Non-binding +1 votes: Francis De Brabandere, Mohammad Nour El-Din, Gurkan Erdogdu The requested resources in the proposal have been updated to use BVAL to better reflect the project's intention and I'll attach the results email to the proposal for history. Thanks, Donald Woods On 2/23/10 10:57 AM, Donald Woods wrote: Given the lack of response on the proposal and the push from our champion to get moving :-), I'll assume lazy consensus and call a vote. I would like to present for a vote the following proposal to be sponsored by the Incubator PMC for a new Validation podling. The goal is to build a community around delivering a JSR-303 Bean Validation implementation based on a new incoming codebase from Agimatec GmbH. The proposal is available on the wiki at and included below: http://wiki.apache.org/incubator/ValidationProposal [] +1 to accept Validation into the Incubator [] 0 don't care [] -1 object and reason why. Thanks, Donald Woods Proposal text from the wiki Validation Abstract The Validation project will deliver an implementation of the Bean Validation Specification (JSR303) Proposal The initial Validation codebase will use the Agimatec Validation source, which is an implementation of the Bean Validation Specification (JSR303). Although the destination of the Validation podling is not fixed, the idea is that it will graduate to Apache Commons and replace the existing Validator 1.x component as a new 2.0 codebase. Background Agimatec Validation has been developed by Agimatec Gmbh and is about 90% complete towards implementing the JSR303 specification. The Agimatec-Validation project is currently hosted on Google Code and is ASL 2.0 licensed. Agimatec has no intention to complete or maintain the implementation but has given the lead developer permission to continue working on the project on his own time. A number of existing Apache projects (Geronimo, OpenJPA, MyFaces, OpenEJB, Commons) are interested in an implementation of the Bean Validation specification and Donald Woods suggested adopting the Agimatec Validation code rather than starting from scratch. Rationale There is currently no Apache project focused on providing a JSR-303 implementation. The existing Commons Validator 1.x project codebase does not include support for Java 5 annotations and predates the JSR-303 specification effort. By using the Agimatec-Validation code, we can bootstrap the effort to create a Validator 2 release and focus on polishing/enhancing the code, certification activities and integration and support of other Apache projects. Current Status Agimatec Validation and is about 95% complete towards implementing the JSR303 specification. An SGA for the Agimatec Validation has been received and on file from Agimatec Gmbh. Meritocracy As a majority of the initial project members are existing ASF committers, we recognize the desirability of running the project as a meritocracy. We are eager to engage other members of the community and operate to the standard of meritocracy that Apache emphasizes; we believe this is the most effective method of growing our community and enabling widespread adoption. Community Even though the reference implementation for the JSR-303 Bean Validation specification is licensed under ASL 2.0, it is not being developed with meritocracy in mind, as the release process is controlled by the JBoss division of Red Hat to meet their own product needs. Validation aims to build a community of developers interested in the definition and delivery of a JSR-303 compliant runtime, which can be reused as a common component by a number of different projects (like Geronimo, OpenJPA, MyFaces, ) By maintaining independence of the target runtime, it is our intention to build the broadest possible community of developers. Core Developers The lead developer from the Agimatec Validation project will be joined by a number of committers from existing ASF projects. Alignment The purpose of Validation is to develop a certified implementation of JSR-303. Some components may be developed and delivered by other Apache projects, like: * Bean Validation 1.0 spec API - Apache Geronimo Specs subproject * JSF2 integration - MyFaces ExtVal components Known Risks The current JSR-303 portions of the Agimatec-Validation code was developed by a single developer from Agimatec (Roman) with no available documents on the structure of the code. Orphaned Products The project will be implementing the JSR-303
Re: [VOTE] [PROPOSAL] Validation incubator for JSR-303 Bean Validation
On Feb 23, 2010, at 4:03 PM, Nick Kew wrote: On Tue, 23 Feb 2010 12:51:35 -0500 Donald Woods dwo...@apache.org wrote: I'm open to suggestions BeanValidation, OpenValidation, Validera, ... Any of those work for me, though OpenValidation has a hint of the same problem. BeanValidation might be ideal, and scans better than, say JSR303-Validation :) Most likely outcome -- this ends up becoming Commons Validator version 2. If project decides to go TLP, the BeanValidation would be good with me. I would certainly expect this to be resolved by the community for graduation. --kevan - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] [PROPOSAL] Validation incubator for JSR-303 Bean Validation
Given the feedback so far, I'm leaning towards BeanValidation as the name and BVAL as the short name (for JIRA and mailing lists), since this is a new codebase and not a natural follow-on to Common Validator 1.x. There are features in Validator 1.x that will probably never be implemented in this codebase (like JSP extensions) as this will be handled by MyFaces, so any users seeing a new commons-validator-2.0 may be surprised that nothing is backwards compatible If we decide to update the project name and resource names now, does that require a new vote? -Donald On 2/26/10 2:01 PM, Kevan Miller wrote: On Feb 23, 2010, at 4:03 PM, Nick Kew wrote: On Tue, 23 Feb 2010 12:51:35 -0500 Donald Woods dwo...@apache.org wrote: I'm open to suggestions BeanValidation, OpenValidation, Validera, ... Any of those work for me, though OpenValidation has a hint of the same problem. BeanValidation might be ideal, and scans better than, say JSR303-Validation :) Most likely outcome -- this ends up becoming Commons Validator version 2. If project decides to go TLP, the BeanValidation would be good with me. I would certainly expect this to be resolved by the community for graduation. --kevan - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] [PROPOSAL] Validation incubator for JSR-303 Bean Validation
Hi Donald, Names are a common issue to be resolved *during* incubation. See JSecurity mail threads for a somewhat extreme example. So, no, don't restart the vote. Craig On Feb 26, 2010, at 11:18 AM, Donald Woods wrote: Given the feedback so far, I'm leaning towards BeanValidation as the name and BVAL as the short name (for JIRA and mailing lists), since this is a new codebase and not a natural follow-on to Common Validator 1.x. There are features in Validator 1.x that will probably never be implemented in this codebase (like JSP extensions) as this will be handled by MyFaces, so any users seeing a new commons-validator-2.0 may be surprised that nothing is backwards compatible If we decide to update the project name and resource names now, does that require a new vote? -Donald On 2/26/10 2:01 PM, Kevan Miller wrote: On Feb 23, 2010, at 4:03 PM, Nick Kew wrote: On Tue, 23 Feb 2010 12:51:35 -0500 Donald Woods dwo...@apache.org wrote: I'm open to suggestions BeanValidation, OpenValidation, Validera, ... Any of those work for me, though OpenValidation has a hint of the same problem. BeanValidation might be ideal, and scans better than, say JSR303-Validation :) Most likely outcome -- this ends up becoming Commons Validator version 2. If project decides to go TLP, the BeanValidation would be good with me. I would certainly expect this to be resolved by the community for graduation. --kevan - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org Craig L Russell Architect, Sun Java Enterprise System http://db.apache.org/jdo 408 276-5638 mailto:craig.russ...@sun.com P.S. A good JDO? O, Gasp! - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] [PROPOSAL] Validation incubator for JSR-303 Bean Validation
On 26 Feb 2010, at 19:01, Kevan Miller wrote: On Feb 23, 2010, at 4:03 PM, Nick Kew wrote: On Tue, 23 Feb 2010 12:51:35 -0500 Donald Woods dwo...@apache.org wrote: I'm open to suggestions BeanValidation, OpenValidation, Validera, ... Any of those work for me, though OpenValidation has a hint of the same problem. BeanValidation might be ideal, and scans better than, say JSR303-Validation :) Most likely outcome -- this ends up becoming Commons Validator version 2. If project decides to go TLP, the BeanValidation would be good with me. I would certainly expect this to be resolved by the community for graduation. Sounds OK to me. Since it looks as if my previous reply got lost in the ether, let me confirm, I'm happy to withdraw my -1 on the basis that the issue has been raised and will be resolved before or during incubation. -- Nick Kew - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] [PROPOSAL] Validation incubator for JSR-303 Bean Validation
Allow me to introduce an Arabic name, cause I really would like to see a project in a well known open community like ASF with an Arabic name at least for once :D. The Arabic word for validation is Mohaqeq, which also means to investigate the validity of something. Thoughts ? On Tue, Feb 23, 2010 at 11:03 PM, Nick Kew n...@apache.org wrote: On Tue, 23 Feb 2010 12:51:35 -0500 Donald Woods dwo...@apache.org wrote: I'm open to suggestions BeanValidation, OpenValidation, Validera, ... Any of those work for me, though OpenValidation has a hint of the same problem. BeanValidation might be ideal, and scans better than, say JSR303-Validation :) I'm looking at it from a perspective of not polluting global namespace. Someone who's never heard of it (or even Java beans) might be looking for validation of their own process of interest, whether it be in a computing field (HTML validation, signature validation, ...) or somewhere completely different (Tax return validation, Fire Safety Compliance Validation ...). A project called Validation will turn up when they google - especially if someone's successive blog entries are about [this] Validation and my tax return. So the name should carry some hint about it. -- Nick Kew - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.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: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] [PROPOSAL] Validation incubator for JSR-303 Bean Validation
+1 (non-binding). OpenBeanValidation as a name will be cool :) Thanks; --Gurkan 2010/2/23 Donald Woods dwo...@apache.org Given the lack of response on the proposal and the push from our champion to get moving :-), I'll assume lazy consensus and call a vote. I would like to present for a vote the following proposal to be sponsored by the Incubator PMC for a new Validation podling. The goal is to build a community around delivering a JSR-303 Bean Validation implementation based on a new incoming codebase from Agimatec GmbH. The proposal is available on the wiki at and included below: http://wiki.apache.org/incubator/ValidationProposal [] +1 to accept Validation into the Incubator [] 0 don't care [] -1 object and reason why. Thanks, Donald Woods Proposal text from the wiki Validation Abstract The Validation project will deliver an implementation of the Bean Validation Specification (JSR303) Proposal The initial Validation codebase will use the Agimatec Validation source, which is an implementation of the Bean Validation Specification (JSR303). Although the destination of the Validation podling is not fixed, the idea is that it will graduate to Apache Commons and replace the existing Validator 1.x component as a new 2.0 codebase. Background Agimatec Validation has been developed by Agimatec Gmbh and is about 90% complete towards implementing the JSR303 specification. The Agimatec-Validation project is currently hosted on Google Code and is ASL 2.0 licensed. Agimatec has no intention to complete or maintain the implementation but has given the lead developer permission to continue working on the project on his own time. A number of existing Apache projects (Geronimo, OpenJPA, MyFaces, OpenEJB, Commons) are interested in an implementation of the Bean Validation specification and Donald Woods suggested adopting the Agimatec Validation code rather than starting from scratch. Rationale There is currently no Apache project focused on providing a JSR-303 implementation. The existing Commons Validator 1.x project codebase does not include support for Java 5 annotations and predates the JSR-303 specification effort. By using the Agimatec-Validation code, we can bootstrap the effort to create a Validator 2 release and focus on polishing/enhancing the code, certification activities and integration and support of other Apache projects. Current Status Agimatec Validation and is about 95% complete towards implementing the JSR303 specification. An SGA for the Agimatec Validation has been received and on file from Agimatec Gmbh. Meritocracy As a majority of the initial project members are existing ASF committers, we recognize the desirability of running the project as a meritocracy. We are eager to engage other members of the community and operate to the standard of meritocracy that Apache emphasizes; we believe this is the most effective method of growing our community and enabling widespread adoption. Community Even though the reference implementation for the JSR-303 Bean Validation specification is licensed under ASL 2.0, it is not being developed with meritocracy in mind, as the release process is controlled by the JBoss division of Red Hat to meet their own product needs. Validation aims to build a community of developers interested in the definition and delivery of a JSR-303 compliant runtime, which can be reused as a common component by a number of different projects (like Geronimo, OpenJPA, MyFaces, ) By maintaining independence of the target runtime, it is our intention to build the broadest possible community of developers. Core Developers The lead developer from the Agimatec Validation project will be joined by a number of committers from existing ASF projects. Alignment The purpose of Validation is to develop a certified implementation of JSR-303. Some components may be developed and delivered by other Apache projects, like: * Bean Validation 1.0 spec API - Apache Geronimo Specs subproject * JSF2 integration - MyFaces ExtVal components Known Risks The current JSR-303 portions of the Agimatec-Validation code was developed by a single developer from Agimatec (Roman) with no available documents on the structure of the code. Orphaned Products The project will be implementing the JSR-303 Bean Validation specification, which is a required component for both the Web and Full profiles of Java EE 6. There is minimal risk of this work becoming non-strategic and the contributors are confident that a larger community will form within the project in a relatively short space of time. Inexperience with Open Source Many of the committers have experience working in one or more open source projects including Apache Commons, Geronimo, OpenJPA, OpenEJB, OpenWebBeans and MyFaces. Homogeneous Developers The list of initial committers are geographically distributed across
Re: [VOTE] [PROPOSAL] Validation incubator for JSR-303 Bean Validation
:-) that's OK, but somehow I like more fancy names. -M On Thu, Feb 25, 2010 at 3:06 PM, Gurkan Erdogdu cgurkanerdo...@gmail.com wrote: +1 (non-binding). OpenBeanValidation as a name will be cool :) Thanks; --Gurkan 2010/2/23 Donald Woods dwo...@apache.org Given the lack of response on the proposal and the push from our champion to get moving :-), I'll assume lazy consensus and call a vote. I would like to present for a vote the following proposal to be sponsored by the Incubator PMC for a new Validation podling. The goal is to build a community around delivering a JSR-303 Bean Validation implementation based on a new incoming codebase from Agimatec GmbH. The proposal is available on the wiki at and included below: http://wiki.apache.org/incubator/ValidationProposal [] +1 to accept Validation into the Incubator [] 0 don't care [] -1 object and reason why. Thanks, Donald Woods Proposal text from the wiki Validation Abstract The Validation project will deliver an implementation of the Bean Validation Specification (JSR303) Proposal The initial Validation codebase will use the Agimatec Validation source, which is an implementation of the Bean Validation Specification (JSR303). Although the destination of the Validation podling is not fixed, the idea is that it will graduate to Apache Commons and replace the existing Validator 1.x component as a new 2.0 codebase. Background Agimatec Validation has been developed by Agimatec Gmbh and is about 90% complete towards implementing the JSR303 specification. The Agimatec-Validation project is currently hosted on Google Code and is ASL 2.0 licensed. Agimatec has no intention to complete or maintain the implementation but has given the lead developer permission to continue working on the project on his own time. A number of existing Apache projects (Geronimo, OpenJPA, MyFaces, OpenEJB, Commons) are interested in an implementation of the Bean Validation specification and Donald Woods suggested adopting the Agimatec Validation code rather than starting from scratch. Rationale There is currently no Apache project focused on providing a JSR-303 implementation. The existing Commons Validator 1.x project codebase does not include support for Java 5 annotations and predates the JSR-303 specification effort. By using the Agimatec-Validation code, we can bootstrap the effort to create a Validator 2 release and focus on polishing/enhancing the code, certification activities and integration and support of other Apache projects. Current Status Agimatec Validation and is about 95% complete towards implementing the JSR303 specification. An SGA for the Agimatec Validation has been received and on file from Agimatec Gmbh. Meritocracy As a majority of the initial project members are existing ASF committers, we recognize the desirability of running the project as a meritocracy. We are eager to engage other members of the community and operate to the standard of meritocracy that Apache emphasizes; we believe this is the most effective method of growing our community and enabling widespread adoption. Community Even though the reference implementation for the JSR-303 Bean Validation specification is licensed under ASL 2.0, it is not being developed with meritocracy in mind, as the release process is controlled by the JBoss division of Red Hat to meet their own product needs. Validation aims to build a community of developers interested in the definition and delivery of a JSR-303 compliant runtime, which can be reused as a common component by a number of different projects (like Geronimo, OpenJPA, MyFaces, ) By maintaining independence of the target runtime, it is our intention to build the broadest possible community of developers. Core Developers The lead developer from the Agimatec Validation project will be joined by a number of committers from existing ASF projects. Alignment The purpose of Validation is to develop a certified implementation of JSR-303. Some components may be developed and delivered by other Apache projects, like: * Bean Validation 1.0 spec API - Apache Geronimo Specs subproject * JSF2 integration - MyFaces ExtVal components Known Risks The current JSR-303 portions of the Agimatec-Validation code was developed by a single developer from Agimatec (Roman) with no available documents on the structure of the code. Orphaned Products The project will be implementing the JSR-303 Bean Validation specification, which is a required component for both the Web and Full profiles of Java EE 6. There is minimal risk of this work becoming non-strategic and the contributors are confident that a larger community will form within the project in a relatively short space of time. Inexperience with Open Source Many of the committers have experience working in one or more open source projects including Apache Commons, Geronimo,
Re: [VOTE] [PROPOSAL] Validation incubator for JSR-303 Bean Validation
The proposal says that this will take over for Commons Validator. Why are we still discussing names? We already have one, Commons Validator. On Thu, Feb 25, 2010 at 9:06 AM, Gurkan Erdogdu cgurkanerdo...@gmail.com wrote: +1 (non-binding). OpenBeanValidation as a name will be cool :) Thanks; --Gurkan 2010/2/23 Donald Woods dwo...@apache.org Given the lack of response on the proposal and the push from our champion to get moving :-), I'll assume lazy consensus and call a vote. I would like to present for a vote the following proposal to be sponsored by the Incubator PMC for a new Validation podling. The goal is to build a community around delivering a JSR-303 Bean Validation implementation based on a new incoming codebase from Agimatec GmbH. The proposal is available on the wiki at and included below: http://wiki.apache.org/incubator/ValidationProposal [] +1 to accept Validation into the Incubator [] 0 don't care [] -1 object and reason why. Thanks, Donald Woods Proposal text from the wiki Validation Abstract The Validation project will deliver an implementation of the Bean Validation Specification (JSR303) Proposal The initial Validation codebase will use the Agimatec Validation source, which is an implementation of the Bean Validation Specification (JSR303). Although the destination of the Validation podling is not fixed, the idea is that it will graduate to Apache Commons and replace the existing Validator 1.x component as a new 2.0 codebase. Background Agimatec Validation has been developed by Agimatec Gmbh and is about 90% complete towards implementing the JSR303 specification. The Agimatec-Validation project is currently hosted on Google Code and is ASL 2.0 licensed. Agimatec has no intention to complete or maintain the implementation but has given the lead developer permission to continue working on the project on his own time. A number of existing Apache projects (Geronimo, OpenJPA, MyFaces, OpenEJB, Commons) are interested in an implementation of the Bean Validation specification and Donald Woods suggested adopting the Agimatec Validation code rather than starting from scratch. Rationale There is currently no Apache project focused on providing a JSR-303 implementation. The existing Commons Validator 1.x project codebase does not include support for Java 5 annotations and predates the JSR-303 specification effort. By using the Agimatec-Validation code, we can bootstrap the effort to create a Validator 2 release and focus on polishing/enhancing the code, certification activities and integration and support of other Apache projects. Current Status Agimatec Validation and is about 95% complete towards implementing the JSR303 specification. An SGA for the Agimatec Validation has been received and on file from Agimatec Gmbh. Meritocracy As a majority of the initial project members are existing ASF committers, we recognize the desirability of running the project as a meritocracy. We are eager to engage other members of the community and operate to the standard of meritocracy that Apache emphasizes; we believe this is the most effective method of growing our community and enabling widespread adoption. Community Even though the reference implementation for the JSR-303 Bean Validation specification is licensed under ASL 2.0, it is not being developed with meritocracy in mind, as the release process is controlled by the JBoss division of Red Hat to meet their own product needs. Validation aims to build a community of developers interested in the definition and delivery of a JSR-303 compliant runtime, which can be reused as a common component by a number of different projects (like Geronimo, OpenJPA, MyFaces, ) By maintaining independence of the target runtime, it is our intention to build the broadest possible community of developers. Core Developers The lead developer from the Agimatec Validation project will be joined by a number of committers from existing ASF projects. Alignment The purpose of Validation is to develop a certified implementation of JSR-303. Some components may be developed and delivered by other Apache projects, like: * Bean Validation 1.0 spec API - Apache Geronimo Specs subproject * JSF2 integration - MyFaces ExtVal components Known Risks The current JSR-303 portions of the Agimatec-Validation code was developed by a single developer from Agimatec (Roman) with no available documents on the structure of the code. Orphaned Products The project will be implementing the JSR-303 Bean Validation specification, which is a required component for both the Web and Full profiles of Java EE 6. There is minimal risk of this work becoming non-strategic and the contributors are confident that a larger community will form within the project in a relatively short space of time. Inexperience with Open Source Many of the committers have
Re: [VOTE] [PROPOSAL] Validation incubator for JSR-303 Bean Validation
On 2/23/10 10:57 AM, Donald Woods wrote: Given the lack of response on the proposal and the push from our champion to get moving :-), I'll assume lazy consensus and call a vote. I would like to present for a vote the following proposal to be sponsored by the Incubator PMC for a new Validation podling. The goal is to build a community around delivering a JSR-303 Bean Validation implementation based on a new incoming codebase from Agimatec GmbH. The proposal is available on the wiki at and included below: http://wiki.apache.org/incubator/ValidationProposal [] +1 to accept Validation into the Incubator [] 0 don't care [] -1 object and reason why. +1 Bill - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] [PROPOSAL] Validation incubator for JSR-303 Bean Validation
+1 Martijn - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] [PROPOSAL] Validation incubator for JSR-303 Bean Validation
+1 (non-binding) On Wed, Feb 24, 2010 at 10:14 AM, Martijn Dashorst martijn.dasho...@gmail.com wrote: +1 Martijn - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.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: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] [PROPOSAL] Validation incubator for JSR-303 Bean Validation
+1 a big one of course! I communicated with agimatec-validator guys a few times and they needed at longest 4 hours to respond to my questions and apply my patches :) This project will be a great add to Apacheland! LieGrue, strub --- Matthias Wessendorf mat...@apache.org schrieb am Mi, 24.2.2010: Von: Matthias Wessendorf mat...@apache.org Betreff: Re: [VOTE] [PROPOSAL] Validation incubator for JSR-303 Bean Validation An: general@incubator.apache.org, Mark Struberg strub...@yahoo.de Datum: Mittwoch, 24. Februar, 2010 04:22 Uhr +1 to accept Validation into the Incubator afterwards we still can see where it actually ends up however I for sure want to see this at Apache. If you guys need a champion or mentor, count me in !! -M On Tue, Feb 23, 2010 at 11:45 PM, Donald Woods dwo...@apache.org wrote: We're leaving the TLP/sub-project decision till graduation... -Donald On 2/23/10 5:36 PM, Brett Porter wrote: As I understand it from the proposal, they intend to be Apache Commons Validation. On 24/02/2010, at 4:19 AM, Nick Kew wrote: On Tue, 23 Feb 2010 10:57:33 -0500 Donald Woods dwo...@apache.org wrote: Given the lack of response on the proposal and the push from our champion to get moving :-), I'll assume lazy consensus and call a vote. I would like to present for a vote the following proposal to be sponsored by the Incubator PMC for a new Validation podling. The goal is to build a community around delivering a JSR-303 Bean Validation implementation based on a new incoming codebase from Agimatec GmbH. The proposal is available on the wiki at and included below: http://wiki.apache.org/incubator/ValidationProposal -1 to a project that could end up being called Apache Validation or just Validation. That's too big/general a word for a project name. No objection under a changed name. I'd suggest adding an adjective to indicate what is being validated. -- Nick Kew - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf __ Do You Yahoo!? Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails. http://mail.yahoo.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] [PROPOSAL] Validation incubator for JSR-303 Bean Validation
We already have Apache Commons Validator. Why not just bring this code into that project? On Tue, Feb 23, 2010 at 5:36 PM, Brett Porter br...@apache.org wrote: As I understand it from the proposal, they intend to be Apache Commons Validation. On 24/02/2010, at 4:19 AM, Nick Kew wrote: On Tue, 23 Feb 2010 10:57:33 -0500 Donald Woods dwo...@apache.org wrote: Given the lack of response on the proposal and the push from our champion to get moving :-), I'll assume lazy consensus and call a vote. I would like to present for a vote the following proposal to be sponsored by the Incubator PMC for a new Validation podling. The goal is to build a community around delivering a JSR-303 Bean Validation implementation based on a new incoming codebase from Agimatec GmbH. The proposal is available on the wiki at and included below: http://wiki.apache.org/incubator/ValidationProposal -1 to a project that could end up being called Apache Validation or just Validation. That's too big/general a word for a project name. No objection under a changed name. I'd suggest adding an adjective to indicate what is being validated. -- Nick Kew - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] [PROPOSAL] Validation incubator for JSR-303 Bean Validation
On Feb 24, 2010, at 8:18 AM, James Carman wrote: We already have Apache Commons Validator. Why not just bring this code into that project? Heh. That's been pretty well discussed, already, by both Commons and Incubator. You can scan the logs for details. The subject was [PROPOSAL] Validation incubator for JSR-303 Bean Validation. I think the following sums up where we landed on that issue (at least it pretty well sums up where I landed on the issue): On Jan 18, 2010, at 9:55 PM, Noel J. Bergman wrote: Kevan Miller wrote: I think we'd agree that a fair amount of community building will be required for this new codebase and group of committers. [However,] given the small makeup of the Commons Validator community, I don't think it's reasonable to expect the Commons community to do this community building. That seems a cogent enough explanation to warrant Incubation. Thank you. I also believe that when you talk about multiple projects collaborating actively on a shared, but separately useable, codebase, a TLP is often justified. --kevan - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] [PROPOSAL] Validation incubator for JSR-303 Bean Validation
+1 --kevan On Feb 23, 2010, at 10:57 AM, Donald Woods wrote: Given the lack of response on the proposal and the push from our champion to get moving :-), I'll assume lazy consensus and call a vote. I would like to present for a vote the following proposal to be sponsored by the Incubator PMC for a new Validation podling. The goal is to build a community around delivering a JSR-303 Bean Validation implementation based on a new incoming codebase from Agimatec GmbH. The proposal is available on the wiki at and included below: http://wiki.apache.org/incubator/ValidationProposal [] +1 to accept Validation into the Incubator [] 0 don't care [] -1 object and reason why. Thanks, Donald Woods Proposal text from the wiki Validation Abstract The Validation project will deliver an implementation of the Bean Validation Specification (JSR303) Proposal The initial Validation codebase will use the Agimatec Validation source, which is an implementation of the Bean Validation Specification (JSR303). Although the destination of the Validation podling is not fixed, the idea is that it will graduate to Apache Commons and replace the existing Validator 1.x component as a new 2.0 codebase. Background Agimatec Validation has been developed by Agimatec Gmbh and is about 90% complete towards implementing the JSR303 specification. The Agimatec-Validation project is currently hosted on Google Code and is ASL 2.0 licensed. Agimatec has no intention to complete or maintain the implementation but has given the lead developer permission to continue working on the project on his own time. A number of existing Apache projects (Geronimo, OpenJPA, MyFaces, OpenEJB, Commons) are interested in an implementation of the Bean Validation specification and Donald Woods suggested adopting the Agimatec Validation code rather than starting from scratch. Rationale There is currently no Apache project focused on providing a JSR-303 implementation. The existing Commons Validator 1.x project codebase does not include support for Java 5 annotations and predates the JSR-303 specification effort. By using the Agimatec-Validation code, we can bootstrap the effort to create a Validator 2 release and focus on polishing/enhancing the code, certification activities and integration and support of other Apache projects. Current Status Agimatec Validation and is about 95% complete towards implementing the JSR303 specification. An SGA for the Agimatec Validation has been received and on file from Agimatec Gmbh. Meritocracy As a majority of the initial project members are existing ASF committers, we recognize the desirability of running the project as a meritocracy. We are eager to engage other members of the community and operate to the standard of meritocracy that Apache emphasizes; we believe this is the most effective method of growing our community and enabling widespread adoption. Community Even though the reference implementation for the JSR-303 Bean Validation specification is licensed under ASL 2.0, it is not being developed with meritocracy in mind, as the release process is controlled by the JBoss division of Red Hat to meet their own product needs. Validation aims to build a community of developers interested in the definition and delivery of a JSR-303 compliant runtime, which can be reused as a common component by a number of different projects (like Geronimo, OpenJPA, MyFaces, ) By maintaining independence of the target runtime, it is our intention to build the broadest possible community of developers. Core Developers The lead developer from the Agimatec Validation project will be joined by a number of committers from existing ASF projects. Alignment The purpose of Validation is to develop a certified implementation of JSR-303. Some components may be developed and delivered by other Apache projects, like: * Bean Validation 1.0 spec API - Apache Geronimo Specs subproject * JSF2 integration - MyFaces ExtVal components Known Risks The current JSR-303 portions of the Agimatec-Validation code was developed by a single developer from Agimatec (Roman) with no available documents on the structure of the code. Orphaned Products The project will be implementing the JSR-303 Bean Validation specification, which is a required component for both the Web and Full profiles of Java EE 6. There is minimal risk of this work becoming non-strategic and the contributors are confident that a larger community will form within the project in a relatively short space of time. Inexperience with Open Source Many of the committers have experience working in one or more open source projects including Apache Commons, Geronimo, OpenJPA, OpenEJB, OpenWebBeans and MyFaces. Homogeneous Developers The list of initial committers are geographically distributed across the U.S., Europe and
Re: [VOTE] [PROPOSAL] Validation incubator for JSR-303 Bean Validation
Sorry, didn't read the proposal very closely. The idea was that it would be brought into Commons Validator and become the 2.x codebase. I like that idea and I would think it would be wise to go through the incubator to make sure the codebase is donated cleanly to the ASF. My point was mainly about the name. If it takes over the Commons Validator project, then we already have a name. Issue closed. Right? On Wed, Feb 24, 2010 at 8:49 AM, Kevan Miller kevan.mil...@gmail.com wrote: On Feb 24, 2010, at 8:18 AM, James Carman wrote: We already have Apache Commons Validator. Why not just bring this code into that project? Heh. That's been pretty well discussed, already, by both Commons and Incubator. You can scan the logs for details. The subject was [PROPOSAL] Validation incubator for JSR-303 Bean Validation. I think the following sums up where we landed on that issue (at least it pretty well sums up where I landed on the issue): On Jan 18, 2010, at 9:55 PM, Noel J. Bergman wrote: Kevan Miller wrote: I think we'd agree that a fair amount of community building will be required for this new codebase and group of committers. [However,] given the small makeup of the Commons Validator community, I don't think it's reasonable to expect the Commons community to do this community building. That seems a cogent enough explanation to warrant Incubation. Thank you. I also believe that when you talk about multiple projects collaborating actively on a shared, but separately useable, codebase, a TLP is often justified. --kevan - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] [PROPOSAL] Validation incubator for JSR-303 Bean Validation
On Feb 23, 2010, at 10:22 PM, Matthias Wessendorf wrote: +1 to accept Validation into the Incubator afterwards we still can see where it actually ends up however I for sure want to see this at Apache. If you guys need a champion or mentor, count me in !! We have 3 mentors. If you're interested in making it 4, your help would certainly be appreciated! --kevan - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] [PROPOSAL] Validation incubator for JSR-303 Bean Validation
On Feb 24, 2010, at 8:55 AM, James Carman wrote: Sorry, didn't read the proposal very closely. The idea was that it would be brought into Commons Validator and become the 2.x codebase. I like that idea and I would think it would be wise to go through the incubator to make sure the codebase is donated cleanly to the ASF. My point was mainly about the name. If it takes over the Commons Validator project, then we already have a name. Issue closed. Right? Yes. That's how I view it. It's more than code clearance, however. There are processes for that, already. Community building is why it is starting off as an Incubator project. I think graduating to become Commons Validator v2 is a great outcome. But that's something for the new community to decide. --kevan - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] [PROPOSAL] Validation incubator for JSR-303 Bean Validation
On Wed, Feb 24, 2010 at 9:11 AM, Kevan Miller kevan.mil...@gmail.com wrote: Yes. That's how I view it. It's more than code clearance, however. There are processes for that, already. Community building is why it is starting off as an Incubator project. I think graduating to become Commons Validator v2 is a great outcome. But that's something for the new community to decide. With the names on the proposal already interested, it would seem that there's already a community (definitely enough for a Commons project). Heck, I'm the only one who has ever worked on Commons Proxy. The folks who are ASF committers already and they're not Commons committers could become Commons committers pretty easily I'd guess. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] [PROPOSAL] Validation incubator for JSR-303 Bean Validation
+1 Niall On Tue, Feb 23, 2010 at 3:57 PM, Donald Woods dwo...@apache.org wrote: Given the lack of response on the proposal and the push from our champion to get moving :-), I'll assume lazy consensus and call a vote. I would like to present for a vote the following proposal to be sponsored by the Incubator PMC for a new Validation podling. The goal is to build a community around delivering a JSR-303 Bean Validation implementation based on a new incoming codebase from Agimatec GmbH. The proposal is available on the wiki at and included below: http://wiki.apache.org/incubator/ValidationProposal [] +1 to accept Validation into the Incubator [] 0 don't care [] -1 object and reason why. Thanks, Donald Woods Proposal text from the wiki Validation Abstract The Validation project will deliver an implementation of the Bean Validation Specification (JSR303) Proposal The initial Validation codebase will use the Agimatec Validation source, which is an implementation of the Bean Validation Specification (JSR303). Although the destination of the Validation podling is not fixed, the idea is that it will graduate to Apache Commons and replace the existing Validator 1.x component as a new 2.0 codebase. Background Agimatec Validation has been developed by Agimatec Gmbh and is about 90% complete towards implementing the JSR303 specification. The Agimatec-Validation project is currently hosted on Google Code and is ASL 2.0 licensed. Agimatec has no intention to complete or maintain the implementation but has given the lead developer permission to continue working on the project on his own time. A number of existing Apache projects (Geronimo, OpenJPA, MyFaces, OpenEJB, Commons) are interested in an implementation of the Bean Validation specification and Donald Woods suggested adopting the Agimatec Validation code rather than starting from scratch. Rationale There is currently no Apache project focused on providing a JSR-303 implementation. The existing Commons Validator 1.x project codebase does not include support for Java 5 annotations and predates the JSR-303 specification effort. By using the Agimatec-Validation code, we can bootstrap the effort to create a Validator 2 release and focus on polishing/enhancing the code, certification activities and integration and support of other Apache projects. Current Status Agimatec Validation and is about 95% complete towards implementing the JSR303 specification. An SGA for the Agimatec Validation has been received and on file from Agimatec Gmbh. Meritocracy As a majority of the initial project members are existing ASF committers, we recognize the desirability of running the project as a meritocracy. We are eager to engage other members of the community and operate to the standard of meritocracy that Apache emphasizes; we believe this is the most effective method of growing our community and enabling widespread adoption. Community Even though the reference implementation for the JSR-303 Bean Validation specification is licensed under ASL 2.0, it is not being developed with meritocracy in mind, as the release process is controlled by the JBoss division of Red Hat to meet their own product needs. Validation aims to build a community of developers interested in the definition and delivery of a JSR-303 compliant runtime, which can be reused as a common component by a number of different projects (like Geronimo, OpenJPA, MyFaces, ) By maintaining independence of the target runtime, it is our intention to build the broadest possible community of developers. Core Developers The lead developer from the Agimatec Validation project will be joined by a number of committers from existing ASF projects. Alignment The purpose of Validation is to develop a certified implementation of JSR-303. Some components may be developed and delivered by other Apache projects, like: * Bean Validation 1.0 spec API - Apache Geronimo Specs subproject * JSF2 integration - MyFaces ExtVal components Known Risks The current JSR-303 portions of the Agimatec-Validation code was developed by a single developer from Agimatec (Roman) with no available documents on the structure of the code. Orphaned Products The project will be implementing the JSR-303 Bean Validation specification, which is a required component for both the Web and Full profiles of Java EE 6. There is minimal risk of this work becoming non-strategic and the contributors are confident that a larger community will form within the project in a relatively short space of time. Inexperience with Open Source Many of the committers have experience working in one or more open source projects including Apache Commons, Geronimo, OpenJPA, OpenEJB, OpenWebBeans and MyFaces. Homogeneous Developers The list of initial committers are geographically distributed across the U.S., Europe and Africa with no one
Re: [VOTE] [PROPOSAL] Validation incubator for JSR-303 Bean Validation
On Tue, 23 Feb 2010 12:51:35 -0500 Donald Woods dwo...@apache.org wrote: I'm open to suggestions BeanValidation, OpenValidation, Validera, ... Any of those work for me, though OpenValidation has a hint of the same problem. BeanValidation might be ideal, and scans better than, say JSR303-Validation :) I'm looking at it from a perspective of not polluting global namespace. Someone who's never heard of it (or even Java beans) might be looking for validation of their own process of interest, whether it be in a computing field (HTML validation, signature validation, ...) or somewhere completely different (Tax return validation, Fire Safety Compliance Validation ...). A project called Validation will turn up when they google - especially if someone's successive blog entries are about [this] Validation and my tax return. So the name should carry some hint about it. -- Nick Kew - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] Validation incubator for JSR-303 Bean Validation
On Jan 19, 2010, at 11:45 AM, Donald Woods wrote: Thanks. I'll get with Kevan to update the proposal before we finally submit it for a vote. Oops. Donald, we never synced up. My fault. Let's get this moving along. IMO, we should structure the project as a normal incubator project, use incubator mailing list, etc. And let the Incubator process determine where the Validation project ends up in Apache. I certainly hope that is Commons. --kevan - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] Validation incubator for JSR-303 Bean Validation
No problem. I've updated the Required Resources and Sponsoring Entity sections and will start the vote on another thread. Thanks. -Donald On 2/23/10 10:00 AM, Kevan Miller wrote: On Jan 19, 2010, at 11:45 AM, Donald Woods wrote: Thanks. I'll get with Kevan to update the proposal before we finally submit it for a vote. Oops. Donald, we never synced up. My fault. Let's get this moving along. IMO, we should structure the project as a normal incubator project, use incubator mailing list, etc. And let the Incubator process determine where the Validation project ends up in Apache. I certainly hope that is Commons. --kevan - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[VOTE] [PROPOSAL] Validation incubator for JSR-303 Bean Validation
Given the lack of response on the proposal and the push from our champion to get moving :-), I'll assume lazy consensus and call a vote. I would like to present for a vote the following proposal to be sponsored by the Incubator PMC for a new Validation podling. The goal is to build a community around delivering a JSR-303 Bean Validation implementation based on a new incoming codebase from Agimatec GmbH. The proposal is available on the wiki at and included below: http://wiki.apache.org/incubator/ValidationProposal [] +1 to accept Validation into the Incubator [] 0 don't care [] -1 object and reason why. Thanks, Donald Woods Proposal text from the wiki Validation Abstract The Validation project will deliver an implementation of the Bean Validation Specification (JSR303) Proposal The initial Validation codebase will use the Agimatec Validation source, which is an implementation of the Bean Validation Specification (JSR303). Although the destination of the Validation podling is not fixed, the idea is that it will graduate to Apache Commons and replace the existing Validator 1.x component as a new 2.0 codebase. Background Agimatec Validation has been developed by Agimatec Gmbh and is about 90% complete towards implementing the JSR303 specification. The Agimatec-Validation project is currently hosted on Google Code and is ASL 2.0 licensed. Agimatec has no intention to complete or maintain the implementation but has given the lead developer permission to continue working on the project on his own time. A number of existing Apache projects (Geronimo, OpenJPA, MyFaces, OpenEJB, Commons) are interested in an implementation of the Bean Validation specification and Donald Woods suggested adopting the Agimatec Validation code rather than starting from scratch. Rationale There is currently no Apache project focused on providing a JSR-303 implementation. The existing Commons Validator 1.x project codebase does not include support for Java 5 annotations and predates the JSR-303 specification effort. By using the Agimatec-Validation code, we can bootstrap the effort to create a Validator 2 release and focus on polishing/enhancing the code, certification activities and integration and support of other Apache projects. Current Status Agimatec Validation and is about 95% complete towards implementing the JSR303 specification. An SGA for the Agimatec Validation has been received and on file from Agimatec Gmbh. Meritocracy As a majority of the initial project members are existing ASF committers, we recognize the desirability of running the project as a meritocracy. We are eager to engage other members of the community and operate to the standard of meritocracy that Apache emphasizes; we believe this is the most effective method of growing our community and enabling widespread adoption. Community Even though the reference implementation for the JSR-303 Bean Validation specification is licensed under ASL 2.0, it is not being developed with meritocracy in mind, as the release process is controlled by the JBoss division of Red Hat to meet their own product needs. Validation aims to build a community of developers interested in the definition and delivery of a JSR-303 compliant runtime, which can be reused as a common component by a number of different projects (like Geronimo, OpenJPA, MyFaces, ) By maintaining independence of the target runtime, it is our intention to build the broadest possible community of developers. Core Developers The lead developer from the Agimatec Validation project will be joined by a number of committers from existing ASF projects. Alignment The purpose of Validation is to develop a certified implementation of JSR-303. Some components may be developed and delivered by other Apache projects, like: * Bean Validation 1.0 spec API - Apache Geronimo Specs subproject * JSF2 integration - MyFaces ExtVal components Known Risks The current JSR-303 portions of the Agimatec-Validation code was developed by a single developer from Agimatec (Roman) with no available documents on the structure of the code. Orphaned Products The project will be implementing the JSR-303 Bean Validation specification, which is a required component for both the Web and Full profiles of Java EE 6. There is minimal risk of this work becoming non-strategic and the contributors are confident that a larger community will form within the project in a relatively short space of time. Inexperience with Open Source Many of the committers have experience working in one or more open source projects including Apache Commons, Geronimo, OpenJPA, OpenEJB, OpenWebBeans and MyFaces. Homogeneous Developers The list of initial committers are geographically distributed across the U.S., Europe and Africa with no one company being associated with a majority of the developers. Many of these initial developers are experienced Apache committers already and all are experienced with working in
Re: [VOTE] [PROPOSAL] Validation incubator for JSR-303 Bean Validation
[x] +1 to accept Validation into the Incubator (non-binding) [] 0 don't care [] -1 object and reason why. Thanks, Donald Woods Proposal text from the wiki Validation Abstract The Validation project will deliver an implementation of the Bean Validation Specification (JSR303) Proposal The initial Validation codebase will use the Agimatec Validation source, which is an implementation of the Bean Validation Specification (JSR303). Although the destination of the Validation podling is not fixed, the idea is that it will graduate to Apache Commons and replace the existing Validator 1.x component as a new 2.0 codebase. Background Agimatec Validation has been developed by Agimatec Gmbh and is about 90% complete towards implementing the JSR303 specification. The Agimatec-Validation project is currently hosted on Google Code and is ASL 2.0 licensed. Agimatec has no intention to complete or maintain the implementation but has given the lead developer permission to continue working on the project on his own time. A number of existing Apache projects (Geronimo, OpenJPA, MyFaces, OpenEJB, Commons) are interested in an implementation of the Bean Validation specification and Donald Woods suggested adopting the Agimatec Validation code rather than starting from scratch. Rationale There is currently no Apache project focused on providing a JSR-303 implementation. The existing Commons Validator 1.x project codebase does not include support for Java 5 annotations and predates the JSR-303 specification effort. By using the Agimatec-Validation code, we can bootstrap the effort to create a Validator 2 release and focus on polishing/enhancing the code, certification activities and integration and support of other Apache projects. Current Status Agimatec Validation and is about 95% complete towards implementing the JSR303 specification. An SGA for the Agimatec Validation has been received and on file from Agimatec Gmbh. Meritocracy As a majority of the initial project members are existing ASF committers, we recognize the desirability of running the project as a meritocracy. We are eager to engage other members of the community and operate to the standard of meritocracy that Apache emphasizes; we believe this is the most effective method of growing our community and enabling widespread adoption. Community Even though the reference implementation for the JSR-303 Bean Validation specification is licensed under ASL 2.0, it is not being developed with meritocracy in mind, as the release process is controlled by the JBoss division of Red Hat to meet their own product needs. Validation aims to build a community of developers interested in the definition and delivery of a JSR-303 compliant runtime, which can be reused as a common component by a number of different projects (like Geronimo, OpenJPA, MyFaces, ) By maintaining independence of the target runtime, it is our intention to build the broadest possible community of developers. Core Developers The lead developer from the Agimatec Validation project will be joined by a number of committers from existing ASF projects. Alignment The purpose of Validation is to develop a certified implementation of JSR-303. Some components may be developed and delivered by other Apache projects, like: * Bean Validation 1.0 spec API - Apache Geronimo Specs subproject * JSF2 integration - MyFaces ExtVal components Known Risks The current JSR-303 portions of the Agimatec-Validation code was developed by a single developer from Agimatec (Roman) with no available documents on the structure of the code. Orphaned Products The project will be implementing the JSR-303 Bean Validation specification, which is a required component for both the Web and Full profiles of Java EE 6. There is minimal risk of this work becoming non-strategic and the contributors are confident that a larger community will form within the project in a relatively short space of time. Inexperience with Open Source Many of the committers have experience working in one or more open source projects including Apache Commons, Geronimo, OpenJPA, OpenEJB, OpenWebBeans and MyFaces. Homogeneous Developers The list of initial committers are geographically distributed across the U.S., Europe and Africa with no one company being associated with a majority of the developers. Many of these initial developers are experienced Apache committers already and all are experienced with working in distributed development communities. It is our hope that, through the incubator, further contributors with a broad background of experience but common interest will become involved with this project. Reliance on Salaried Developers To the best of our knowledge, none of the initial committers are being paid to develop code for this project. Relationships with Other Apache Products A number of existing ASF projects
Re: [VOTE] [PROPOSAL] Validation incubator for JSR-303 Bean Validation
+1 Go for it. Craig On Feb 23, 2010, at 7:57 AM, Donald Woods wrote: Given the lack of response on the proposal and the push from our champion to get moving :-), I'll assume lazy consensus and call a vote. I would like to present for a vote the following proposal to be sponsored by the Incubator PMC for a new Validation podling. The goal is to build a community around delivering a JSR-303 Bean Validation implementation based on a new incoming codebase from Agimatec GmbH. The proposal is available on the wiki at and included below: http://wiki.apache.org/incubator/ValidationProposal [] +1 to accept Validation into the Incubator [] 0 don't care [] -1 object and reason why. Thanks, Donald Woods Proposal text from the wiki Validation Abstract The Validation project will deliver an implementation of the Bean Validation Specification (JSR303) Proposal The initial Validation codebase will use the Agimatec Validation source, which is an implementation of the Bean Validation Specification (JSR303). Although the destination of the Validation podling is not fixed, the idea is that it will graduate to Apache Commons and replace the existing Validator 1.x component as a new 2.0 codebase. Background Agimatec Validation has been developed by Agimatec Gmbh and is about 90% complete towards implementing the JSR303 specification. The Agimatec-Validation project is currently hosted on Google Code and is ASL 2.0 licensed. Agimatec has no intention to complete or maintain the implementation but has given the lead developer permission to continue working on the project on his own time. A number of existing Apache projects (Geronimo, OpenJPA, MyFaces, OpenEJB, Commons) are interested in an implementation of the Bean Validation specification and Donald Woods suggested adopting the Agimatec Validation code rather than starting from scratch. Rationale There is currently no Apache project focused on providing a JSR-303 implementation. The existing Commons Validator 1.x project codebase does not include support for Java 5 annotations and predates the JSR-303 specification effort. By using the Agimatec-Validation code, we can bootstrap the effort to create a Validator 2 release and focus on polishing/enhancing the code, certification activities and integration and support of other Apache projects. Current Status Agimatec Validation and is about 95% complete towards implementing the JSR303 specification. An SGA for the Agimatec Validation has been received and on file from Agimatec Gmbh. Meritocracy As a majority of the initial project members are existing ASF committers, we recognize the desirability of running the project as a meritocracy. We are eager to engage other members of the community and operate to the standard of meritocracy that Apache emphasizes; we believe this is the most effective method of growing our community and enabling widespread adoption. Community Even though the reference implementation for the JSR-303 Bean Validation specification is licensed under ASL 2.0, it is not being developed with meritocracy in mind, as the release process is controlled by the JBoss division of Red Hat to meet their own product needs. Validation aims to build a community of developers interested in the definition and delivery of a JSR-303 compliant runtime, which can be reused as a common component by a number of different projects (like Geronimo, OpenJPA, MyFaces, ) By maintaining independence of the target runtime, it is our intention to build the broadest possible community of developers. Core Developers The lead developer from the Agimatec Validation project will be joined by a number of committers from existing ASF projects. Alignment The purpose of Validation is to develop a certified implementation of JSR-303. Some components may be developed and delivered by other Apache projects, like: * Bean Validation 1.0 spec API - Apache Geronimo Specs subproject * JSF2 integration - MyFaces ExtVal components Known Risks The current JSR-303 portions of the Agimatec-Validation code was developed by a single developer from Agimatec (Roman) with no available documents on the structure of the code. Orphaned Products The project will be implementing the JSR-303 Bean Validation specification, which is a required component for both the Web and Full profiles of Java EE 6. There is minimal risk of this work becoming non-strategic and the contributors are confident that a larger community will form within the project in a relatively short space of time. Inexperience with Open Source Many of the committers have experience working in one or more open source projects including Apache Commons, Geronimo, OpenJPA, OpenEJB, OpenWebBeans and MyFaces. Homogeneous Developers The list of initial committers are geographically distributed across the U.S., Europe and Africa with no one company being associated with a majority of the developers. Many of
Re: [VOTE] [PROPOSAL] Validation incubator for JSR-303 Bean Validation
On Tue, 23 Feb 2010 10:57:33 -0500 Donald Woods dwo...@apache.org wrote: Given the lack of response on the proposal and the push from our champion to get moving :-), I'll assume lazy consensus and call a vote. I would like to present for a vote the following proposal to be sponsored by the Incubator PMC for a new Validation podling. The goal is to build a community around delivering a JSR-303 Bean Validation implementation based on a new incoming codebase from Agimatec GmbH. The proposal is available on the wiki at and included below: http://wiki.apache.org/incubator/ValidationProposal -1 to a project that could end up being called Apache Validation or just Validation. That's too big/general a word for a project name. No objection under a changed name. I'd suggest adding an adjective to indicate what is being validated. -- Nick Kew - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] [PROPOSAL] Validation incubator for JSR-303 Bean Validation
On 02/23/2010 06:19 PM, Nick Kew wrote: On Tue, 23 Feb 2010 10:57:33 -0500 Donald Woods dwo...@apache.org wrote: Given the lack of response on the proposal and the push from our champion to get moving :-), I'll assume lazy consensus and call a vote. I would like to present for a vote the following proposal to be sponsored by the Incubator PMC for a new Validation podling. The goal is to build a community around delivering a JSR-303 Bean Validation implementation based on a new incoming codebase from Agimatec GmbH. The proposal is available on the wiki at and included below: http://wiki.apache.org/incubator/ValidationProposal -1 to a project that could end up being called Apache Validation or just Validation. That's too big/general a word for a project name. No objection under a changed name. I'd suggest adding an adjective to indicate what is being validated. Apache BeanValidation? Cheers Jean-Frederic - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] [PROPOSAL] Validation incubator for JSR-303 Bean Validation
+1 Regards, Alan On Feb 23, 2010, at 7:57 AM, Donald Woods wrote: Given the lack of response on the proposal and the push from our champion to get moving :-), I'll assume lazy consensus and call a vote. I would like to present for a vote the following proposal to be sponsored by the Incubator PMC for a new Validation podling. The goal is to build a community around delivering a JSR-303 Bean Validation implementation based on a new incoming codebase from Agimatec GmbH. The proposal is available on the wiki at and included below: http://wiki.apache.org/incubator/ValidationProposal [] +1 to accept Validation into the Incubator [] 0 don't care [] -1 object and reason why. Thanks, Donald Woods Proposal text from the wiki Validation Abstract The Validation project will deliver an implementation of the Bean Validation Specification (JSR303) Proposal The initial Validation codebase will use the Agimatec Validation source, which is an implementation of the Bean Validation Specification (JSR303). Although the destination of the Validation podling is not fixed, the idea is that it will graduate to Apache Commons and replace the existing Validator 1.x component as a new 2.0 codebase. Background Agimatec Validation has been developed by Agimatec Gmbh and is about 90% complete towards implementing the JSR303 specification. The Agimatec-Validation project is currently hosted on Google Code and is ASL 2.0 licensed. Agimatec has no intention to complete or maintain the implementation but has given the lead developer permission to continue working on the project on his own time. A number of existing Apache projects (Geronimo, OpenJPA, MyFaces, OpenEJB, Commons) are interested in an implementation of the Bean Validation specification and Donald Woods suggested adopting the Agimatec Validation code rather than starting from scratch. Rationale There is currently no Apache project focused on providing a JSR-303 implementation. The existing Commons Validator 1.x project codebase does not include support for Java 5 annotations and predates the JSR-303 specification effort. By using the Agimatec-Validation code, we can bootstrap the effort to create a Validator 2 release and focus on polishing/enhancing the code, certification activities and integration and support of other Apache projects. Current Status Agimatec Validation and is about 95% complete towards implementing the JSR303 specification. An SGA for the Agimatec Validation has been received and on file from Agimatec Gmbh. Meritocracy As a majority of the initial project members are existing ASF committers, we recognize the desirability of running the project as a meritocracy. We are eager to engage other members of the community and operate to the standard of meritocracy that Apache emphasizes; we believe this is the most effective method of growing our community and enabling widespread adoption. Community Even though the reference implementation for the JSR-303 Bean Validation specification is licensed under ASL 2.0, it is not being developed with meritocracy in mind, as the release process is controlled by the JBoss division of Red Hat to meet their own product needs. Validation aims to build a community of developers interested in the definition and delivery of a JSR-303 compliant runtime, which can be reused as a common component by a number of different projects (like Geronimo, OpenJPA, MyFaces, ) By maintaining independence of the target runtime, it is our intention to build the broadest possible community of developers. Core Developers The lead developer from the Agimatec Validation project will be joined by a number of committers from existing ASF projects. Alignment The purpose of Validation is to develop a certified implementation of JSR-303. Some components may be developed and delivered by other Apache projects, like: * Bean Validation 1.0 spec API - Apache Geronimo Specs subproject * JSF2 integration - MyFaces ExtVal components Known Risks The current JSR-303 portions of the Agimatec-Validation code was developed by a single developer from Agimatec (Roman) with no available documents on the structure of the code. Orphaned Products The project will be implementing the JSR-303 Bean Validation specification, which is a required component for both the Web and Full profiles of Java EE 6. There is minimal risk of this work becoming non-strategic and the contributors are confident that a larger community will form within the project in a relatively short space of time. Inexperience with Open Source Many of the committers have experience working in one or more open source projects including Apache Commons, Geronimo, OpenJPA, OpenEJB, OpenWebBeans and MyFaces. Homogeneous Developers The list of initial committers are geographically distributed across the U.S., Europe and Africa with no one company being associated with a majority of the developers. Many of
Re: [VOTE] [PROPOSAL] Validation incubator for JSR-303 Bean Validation
On Feb 23, 2010, at 9:19 AM, Nick Kew wrote: On Tue, 23 Feb 2010 10:57:33 -0500 Donald Woods dwo...@apache.org wrote: Given the lack of response on the proposal and the push from our champion to get moving :-), I'll assume lazy consensus and call a vote. I would like to present for a vote the following proposal to be sponsored by the Incubator PMC for a new Validation podling. The goal is to build a community around delivering a JSR-303 Bean Validation implementation based on a new incoming codebase from Agimatec GmbH. The proposal is available on the wiki at and included below: http://wiki.apache.org/incubator/ValidationProposal -1 to a project that could end up being called Apache Validation or just Validation. That's too big/general a word for a project name. No objection under a changed name. I'd suggest adding an adjective to indicate what is being validated. Interesting point. Not sure that it should be brought up and resolved during a vote. A project's name is always up in the air while it's incubating and should not be a barrier to its being brought in to the Incubator. Regards, Alan - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] [PROPOSAL] Validation incubator for JSR-303 Bean Validation
I'm open to suggestions BeanValidation, OpenValidation, Validera, ... -Donald On 2/23/10 12:27 PM, jean-frederic clere wrote: On 02/23/2010 06:19 PM, Nick Kew wrote: On Tue, 23 Feb 2010 10:57:33 -0500 Donald Woods dwo...@apache.org wrote: Given the lack of response on the proposal and the push from our champion to get moving :-), I'll assume lazy consensus and call a vote. I would like to present for a vote the following proposal to be sponsored by the Incubator PMC for a new Validation podling. The goal is to build a community around delivering a JSR-303 Bean Validation implementation based on a new incoming codebase from Agimatec GmbH. The proposal is available on the wiki at and included below: http://wiki.apache.org/incubator/ValidationProposal -1 to a project that could end up being called Apache Validation or just Validation. That's too big/general a word for a project name. No objection under a changed name. I'd suggest adding an adjective to indicate what is being validated. Apache BeanValidation? Cheers Jean-Frederic - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] [PROPOSAL] Validation incubator for JSR-303 Bean Validation
On Tue, Feb 23, 2010 at 7:57 AM, Donald Woods dwo...@apache.org wrote: Given the lack of response on the proposal and the push from our champion to get moving :-), I'll assume lazy consensus and call a vote. I would like to present for a vote the following proposal to be sponsored by the Incubator PMC for a new Validation podling. The goal is to build a community around delivering a JSR-303 Bean Validation implementation based on a new incoming codebase from Agimatec GmbH. The proposal is available on the wiki at and included below: http://wiki.apache.org/incubator/ValidationProposal [] +1 to accept Validation into the Incubator [] 0 don't care [] -1 object and reason why. +1 to accept Validation into the Incubator -- Luciano Resende http://people.apache.org/~lresende http://twitter.com/lresende1975 http://lresende.blogspot.com/ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] [PROPOSAL] Validation incubator for JSR-303 Bean Validation
As I understand it from the proposal, they intend to be Apache Commons Validation. On 24/02/2010, at 4:19 AM, Nick Kew wrote: On Tue, 23 Feb 2010 10:57:33 -0500 Donald Woods dwo...@apache.org wrote: Given the lack of response on the proposal and the push from our champion to get moving :-), I'll assume lazy consensus and call a vote. I would like to present for a vote the following proposal to be sponsored by the Incubator PMC for a new Validation podling. The goal is to build a community around delivering a JSR-303 Bean Validation implementation based on a new incoming codebase from Agimatec GmbH. The proposal is available on the wiki at and included below: http://wiki.apache.org/incubator/ValidationProposal -1 to a project that could end up being called Apache Validation or just Validation. That's too big/general a word for a project name. No objection under a changed name. I'd suggest adding an adjective to indicate what is being validated. -- Nick Kew - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] [PROPOSAL] Validation incubator for JSR-303 Bean Validation
We're leaving the TLP/sub-project decision till graduation... -Donald On 2/23/10 5:36 PM, Brett Porter wrote: As I understand it from the proposal, they intend to be Apache Commons Validation. On 24/02/2010, at 4:19 AM, Nick Kew wrote: On Tue, 23 Feb 2010 10:57:33 -0500 Donald Woods dwo...@apache.org wrote: Given the lack of response on the proposal and the push from our champion to get moving :-), I'll assume lazy consensus and call a vote. I would like to present for a vote the following proposal to be sponsored by the Incubator PMC for a new Validation podling. The goal is to build a community around delivering a JSR-303 Bean Validation implementation based on a new incoming codebase from Agimatec GmbH. The proposal is available on the wiki at and included below: http://wiki.apache.org/incubator/ValidationProposal -1 to a project that could end up being called Apache Validation or just Validation. That's too big/general a word for a project name. No objection under a changed name. I'd suggest adding an adjective to indicate what is being validated. -- Nick Kew - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] [PROPOSAL] Validation incubator for JSR-303 Bean Validation
+1 to accept Validation into the Incubator afterwards we still can see where it actually ends up however I for sure want to see this at Apache. If you guys need a champion or mentor, count me in !! -M On Tue, Feb 23, 2010 at 11:45 PM, Donald Woods dwo...@apache.org wrote: We're leaving the TLP/sub-project decision till graduation... -Donald On 2/23/10 5:36 PM, Brett Porter wrote: As I understand it from the proposal, they intend to be Apache Commons Validation. On 24/02/2010, at 4:19 AM, Nick Kew wrote: On Tue, 23 Feb 2010 10:57:33 -0500 Donald Woods dwo...@apache.org wrote: Given the lack of response on the proposal and the push from our champion to get moving :-), I'll assume lazy consensus and call a vote. I would like to present for a vote the following proposal to be sponsored by the Incubator PMC for a new Validation podling. The goal is to build a community around delivering a JSR-303 Bean Validation implementation based on a new incoming codebase from Agimatec GmbH. The proposal is available on the wiki at and included below: http://wiki.apache.org/incubator/ValidationProposal -1 to a project that could end up being called Apache Validation or just Validation. That's too big/general a word for a project name. No objection under a changed name. I'd suggest adding an adjective to indicate what is being validated. -- Nick Kew - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] [PROPOSAL] Validation incubator for JSR-303 Bean Validation
On 02/23/2010 04:57 PM, Donald Woods wrote: Given the lack of response on the proposal and the push from our champion to get moving :-), I'll assume lazy consensus and call a vote. I would like to present for a vote the following proposal to be sponsored by the Incubator PMC for a new Validation podling. The goal is to build a community around delivering a JSR-303 Bean Validation implementation based on a new incoming codebase from Agimatec GmbH. The proposal is available on the wiki at and included below: http://wiki.apache.org/incubator/ValidationProposal [X] +1 to accept Validation into the Incubator Cheers Jean-Frederic - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: [PROPOSAL] Validation incubator for JSR-303 Bean Validation
Kevan, Time to restart/finish this discussion. I agree. Seems that things have cooled off a bit. Personally, I'd have been happy to see this move forward either way 1) IP clearance with implementation work in Commons This works only if we're dealing with a CODEBASE and an existing ASF community that takes over it, albeit with the addition of a small number of new members who are part of, but not the entire, developer base for the code. 2) Incubator project with graduation to Commons (or other TLP). This is the correct path if we need to incubate a community. Again, to summarize: we CLEAR code, we INCUBATE communities. We seem to have talked our way into doing nothing. Option 3 is probably not the correct choice. :-) The Geronimo project is going to need a Bean Validation implementation for EE6 compliance. So, I'm confident that there is enough interest to create an implementation at Apache. I'd prefer that it end up in Commons (since this is really an SE technology). However, I can start discussions in the Geronimo community, if that's what it takes. That would be great, but given the criteria above, which direction do you feel that this promotes? --- Noel - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] Validation incubator for JSR-303 Bean Validation
On Dec 30, 2009, at 4:55 PM, Niall Pemberton wrote: This is not quite the scenario. We have a *dormant* component (validator) in Commons and a couple of ASF committers (not commons committers) have shown up proposing to re-write that component to implement the new Bean Valiadation specification. Recently one of those committers proposed adopting this existing code-base written by someone else which is already 80% complete. I was the last active committer on the Commons Validator component and all I'm trying to do is facilitate those that want to revive it and bring in the new code base. So its more a case of other people think Commons would be an appropriate home - so far none of the existing Commons committers has shown any interest in the codebase. Personally my interest in helping make this happen though is now dying 'coz this is way too painful. Time to restart/finish this discussion. Personally, I'd have been happy to see this move forward either way -- 1) IP clearance with implementation work in Commons or 2) Incubator project with graduation to Commons (or other TLP). We seem to have talked our way into doing nothing. The Geronimo project is going to need a Bean Validation implementation for EE6 compliance. So, I'm confident that there is enough interest to create an implementation at Apache. I'd prefer that it end up in Commons (since this is really an SE technology). However, I can start discussions in the Geronimo community, if that's what it takes. --kevan - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] Validation incubator for JSR-303 Bean Validation
On Thu, Dec 31, 2009 at 2:54 PM, Phil Steitz phil.ste...@gmail.com wrote: I don't think weeding out those who consume more than they contribute as an organizing principle would work. It is certainly not the way we have been operating up to now at the ASF. Yes it is. consuming in this context is more like creating more problem for the community. The few cases (that I know of) where merit was revoked or threatened to be revoked, was due to consumption of community energy beyond the contribution given. Cheers -- Niclas Hedhman, Software Developer http://www.qi4j.org - New Energy for Java I live here; http://tinyurl.com/2qq9er I work here; http://tinyurl.com/2ymelc I relax here; http://tinyurl.com/2cgsug - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] Validation incubator for JSR-303 Bean Validation
On Wed, Dec 30, 2009 at 9:55 PM, Niall Pemberton niall.pember...@gmail.com wrote: This is not quite the scenario. We have a *dormant* component (validator) in Commons and a couple of ASF committers (not commons committers) have shown up proposing to re-write that component to implement the new Bean Valiadation specification. Recently one of those committers proposed adopting this existing code-base written by someone else which is already 80% complete. I was the last active committer on the Commons Validator component and all I'm trying to do is facilitate those that want to revive it and bring in the new code base. So its more a case of other people think Commons would be an appropriate home - so far none of the existing Commons committers has shown any interest in the codebase. Personally my interest in helping make this happen though is now dying 'coz this is way too painful. It doesn't have to be painful. This thread has been running a few weeks now if it really is wanted to be done in the Incubator just call a vote on that now. The champion and mentors are Incubator PMC members so it'll likely get enough +1s (though the vote might go more smoothly if the part about using the commons mailing lists is removed). The Commons PMC is effectively saying we don't want to take responsibility and giving it to the Incubator PMC who from the comments on this thread will likely think its ready to graduate almost immediately so can vote to graduate it at the earliest opportunity and give it right back to Commons. Making work for ourselves but so be it. It doesnt look like theres been any comments about this on commons dev or private since the proposal was submitted to the Incubator so it may be worth first asking there again if they'd review this thread and reconsider not doing it via the software grant route. ...ant - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] Validation incubator for JSR-303 Bean Validation
- Original Message From: Phil Steitz phil.ste...@gmail.com To: general@incubator.apache.org Sent: Thu, December 31, 2009 1:54:18 AM Subject: Re: [PROPOSAL] Validation incubator for JSR-303 Bean Validation Joe Schaefer wrote: - Original Message From: Phil Steitz To: general@incubator.apache.org Sent: Wed, December 30, 2009 3:10:47 PM Subject: Re: [PROPOSAL] Validation incubator for JSR-303 Bean Validation Joe Schaefer wrote: - Original Message From: Phil Steitz To: general@incubator.apache.org Sent: Wed, December 30, 2009 1:30:13 PM Subject: Re: [PROPOSAL] Validation incubator for JSR-303 Bean Validation Joe Schaefer wrote: - Original Message From: ant elder To: general@incubator.apache.org Sent: Fri, December 11, 2009 5:22:13 AM Subject: Re: [PROPOSAL] Validation incubator for JSR-303 Bean Validation On Fri, Dec 11, 2009 at 9:56 AM, Niall Pemberton wrote: On Fri, Dec 11, 2009 at 7:56 AM, ant elder wrote: A quick search so there has been some discussion on commons-dev - [1] Does this really need to be incubated - the proposal says its intended to graduate to Apache Commons and replace the existing Validator 1.x component as a new 2.0 codebase, from the discussion on commons-dev everyone seems fine with that out come, and only 2 of the 7 proposed committers are not existing Validator or ASF committers - so couldn't this just go straight to commons as a code grant and make the two new guys committers in recognition of contibuting the new code? I raised this on priv...@commons and reported back to d...@commons on that discussion here: http://markmail.org/message/lkyjl6gaxawspgdt In summary though, there was very little support to go that route and some objections. All commons components share the same set of mailing lists which makes it easier for PMC members to provide oversight for the 30+ components that live there. As part of this proposal we want to use the commons mailing lists for commits and discussion so that by the time this podling is ready to graduate the new committers and Commons PMC will have a better knowledge of each other and there will be no issue with voting in the new committers. The use of the commons mailing lists is in the proposal and was part of the vote held on d...@commons to sponsor this incubation effort: http://markmail.org/message/mqdft736b5vasezs Niall From the first email referenced was Roman ever asked if he'd mind submitting patches for a while to earn Karma if the code did go straight to commons? Seems a bit a of a shame to need to go the whole incubation process just for one commit access. Re the the poddling use the existing commons mailing lists its may be worth pointing out this recent thread: http://apache.markmail.org/message/ifinvq7wqmeoo5ix Commons is badly busted if it can't allow a new person access to his/her own code in a fucking sandbox. Incubating this project because some weenies are uncomfortable about the nature of the meritocracy over in commons isn't the solution: have commons hold a public vote and make an actual decision. If they vote to incubate the damned thing, it's an incredibly stupid decision, but so be it. Hey Joe, the language could be toned down a bit, but I see your point. On the other hand, here is the problem as I see it. In Commons, like other non-Incubator projects, we welcome new contributors and encourage them to get involved in the community and stick around long enough to earn ASF commit. When people show up with significant patches, we ask them to file CLAs before we commit their code and if the contribution is big (not precisely defined, but we have been able to agree in all cases), we ask for a software grant and go through Incubator IP clearance. We have several examples of people showing up with large amounts of code, engaging in the community and contributing patches to their own and other code and earning commit that way. This has worked for us in the past and is consistent with how things are supposed to work - at least as I understand it - at the ASF, outside of the Incubator. If we have changed our (ASF) view on what it means to become a committer, then maybe we are behind the times in Commons. That would be somewhat ironic, since in the Jakarta days we were regularly accused of having too low a bar for commit. What we would have no problem at all with is following the process described above - just do IP clearance / code grant for the code and let the non-ASF committers earn commit. This does not take forever and is not as terrible as some seem to think it is. I can't recall a single failure (someone getting discouraged and giving up) and several successes over the past 6 years. I understand that in the Incubator people get commit immediately
Re: [PROPOSAL] Validation incubator for JSR-303 Bean Validation
On Dec 31, 2009, at 3:40 PM, Joe Schaefer wrote: As I said, we do not have a hard and fast rule on length of time, but this nebulous notion is what makes the ASF work. If that were true the incubator would need to be completely reworked, because the process we use here is basically a filter on those that offer to participate- graduating projects select from their committer rosters who they'd like to carry on as committers or add to the PMC when they go top-level. And the incubator is not your typical ASF project. By design, getting the right to commit is fairly easy. It is necessary to aid projects get off the ground. The point of having a version control system in place is that we can be lax in how we dish out permissions to it *because* it's easy to fix mistakes *after* they happen. The overriding goal is to weed out people who consume more collective energy than they give back, not to bestow an honorific title on those that clear the bar. No, you have it backwards. Merit is earned and with it comes influence. You don't get it instantly and then lose it. I don't think weeding out those who consume more than they contribute as an organizing principle would work. It is certainly not the way we have been operating up to now at the ASF. You have conflated the symbols of authority with true authority- merit has nothing to do with one's committer status. Being a committer doesn't confer instant credibility any more than being a non-committer means one is clueless. If a committer doesn't know how to work productively with his/her peers, his/her work won't have any recogizable merit to those people, which in the end is what matters most. Just because someone has commit doesn't mean they have any control over the direction of a project, or even their own fate- that rests with the PMC. In every ASF community I have been involved in some amount of community participation has had to take place before being granted commit rights. No one wants to find out that a person can't work productively with his/her peers after they have been granted commit rights. This varies from community to community but never have I experienced commit rights being given without some vetting. The closest to that was Commons, which is fairly lenient for people who already have commit rights elsewhere or are a member. But even there some level of commitment has to be demonstrated. On the other hand, in these communities once granted commit rights are rarely taken away unless the person asks to become emeritus or for some fairly extreme reason - which in my experience has been rare. Some projects delay granting commit rights because they also make the person a PMC member at the same time. In others, commit rights are handed out a little more freely but PMC membership takes quite a bit more time. Each project is free to handle it in the way they feel is best for their community. In all these communities anyone who has commit access has more influence then someone who doesn't, if for no other reason than they can take a patch from a Jira issue and commit it while everyone else can't. In most projects even though a committers vote won't officially count their vote on an issue still carries more weight than someone without that right. So to claim that being granted commit rights doesn't have anything to do with one's authority is incorrect. Ralph - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] Validation incubator for JSR-303 Bean Validation
- Original Message From: Ralph Goers ralph.go...@dslextreme.com To: general@incubator.apache.org Sent: Thu, December 31, 2009 9:27:26 PM Subject: Re: [PROPOSAL] Validation incubator for JSR-303 Bean Validation On Dec 31, 2009, at 3:40 PM, Joe Schaefer wrote: As I said, we do not have a hard and fast rule on length of time, but this nebulous notion is what makes the ASF work. If that were true the incubator would need to be completely reworked, because the process we use here is basically a filter on those that offer to participate- graduating projects select from their committer rosters who they'd like to carry on as committers or add to the PMC when they go top-level. And the incubator is not your typical ASF project. By design, getting the right to commit is fairly easy. It is necessary to aid projects get off the ground. The point of having a version control system in place is that we can be lax in how we dish out permissions to it *because* it's easy to fix mistakes *after* they happen. The overriding goal is to weed out people who consume more collective energy than they give back, not to bestow an honorific title on those that clear the bar. No, you have it backwards. Merit is earned and with it comes influence. You don't get it instantly and then lose it. I don't think weeding out those who consume more than they contribute as an organizing principle would work. It is certainly not the way we have been operating up to now at the ASF. You have conflated the symbols of authority with true authority- merit has nothing to do with one's committer status. Being a committer doesn't confer instant credibility any more than being a non-committer means one is clueless. If a committer doesn't know how to work productively with his/her peers, his/her work won't have any recogizable merit to those people, which in the end is what matters most. Just because someone has commit doesn't mean they have any control over the direction of a project, or even their own fate- that rests with the PMC. In every ASF community I have been involved in some amount of community participation has had to take place before being granted commit rights. No one wants to find out that a person can't work productively with his/her peers after they have been granted commit rights. This varies from community to community but never have I experienced commit rights being given without some vetting. The closest to that was Commons, which is fairly lenient for people who already have commit rights elsewhere or are a member. But even there some level of commitment has to be demonstrated. On the other hand, in these communities once granted commit rights are rarely taken away unless the person asks to become emeritus or for some fairly extreme reason - which in my experience has been rare. Some projects delay granting commit rights because they also make the person a PMC member at the same time. In others, commit rights are handed out a little more freely but PMC membership takes quite a bit more time. Each project is free to handle it in the way they feel is best for their community. In all these communities anyone who has commit access has more influence then someone who doesn't, if for no other reason than they can take a patch from a Jira issue and commit it while everyone else can't. In most projects even though a committers vote won't officially count their vote on an issue still carries more weight than someone without that right. So to claim that being granted commit rights doesn't have anything to do with one's authority is incorrect. It is the PMC that controls all aspects of the project, including whatever rights it wishes to confer to committers. Those rights can be distributed one individual at a time or as a class. A committer's opinion may be considered ahead of other people's opionions, but it based on their individual merit, not their accrued status. And in the end it may be completely discarded by the PMC if it so chooses. Look at the Subversion project as an example of a community with a large committer base and a full set of rules for how committers are given the right to work on various aspects of their svn tree. (A full committer in Subversion maps to a PMC member at Apache.) The rules are entirely social in nature, not enforced with authz rules. Getting back to the subject, my primary objection to what's being proposed is that commons should handle this as an ip clearance, not as a project incubation. If commons insists that the individuals in question have to submit patches to their own work product for a while, that is a suboptimal choice but I can respect it. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional
Re: [PROPOSAL] Validation incubator for JSR-303 Bean Validation
On Dec 31, 2009, at 7:20 PM, Joe Schaefer wrote: Getting back to the subject, my primary objection to what's being proposed is that commons should handle this as an ip clearance, not as a project incubation. If commons insists that the individuals in question have to submit patches to their own work product for a while, that is a suboptimal choice but I can respect it. I disagree that it should just be about ip clearance. If the Commons PMC has a history with the committers that come with the code then they surely can judge whether those people would be good members of the community. If they don't have any track record to go on then it is unreasonable to expect them to immediately accept them. The Commons PMC doesn't even do that for Members, except to grant them commit rights to the sandbox. However, IMO it would not be unreasonable to allow the code into the sandbox and give them only commit rights to their component. However, I'm not on the Commons PMC so my opinion is just that. Ralph - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] Validation incubator for JSR-303 Bean Validation
Joe Schaefer wrote: - Original Message From: ant elder antel...@apache.org To: general@incubator.apache.org Sent: Fri, December 11, 2009 5:22:13 AM Subject: Re: [PROPOSAL] Validation incubator for JSR-303 Bean Validation On Fri, Dec 11, 2009 at 9:56 AM, Niall Pemberton wrote: On Fri, Dec 11, 2009 at 7:56 AM, ant elder wrote: A quick search so there has been some discussion on commons-dev - [1] Does this really need to be incubated - the proposal says its intended to graduate to Apache Commons and replace the existing Validator 1.x component as a new 2.0 codebase, from the discussion on commons-dev everyone seems fine with that out come, and only 2 of the 7 proposed committers are not existing Validator or ASF committers - so couldn't this just go straight to commons as a code grant and make the two new guys committers in recognition of contibuting the new code? I raised this on priv...@commons and reported back to d...@commons on that discussion here: http://markmail.org/message/lkyjl6gaxawspgdt In summary though, there was very little support to go that route and some objections. All commons components share the same set of mailing lists which makes it easier for PMC members to provide oversight for the 30+ components that live there. As part of this proposal we want to use the commons mailing lists for commits and discussion so that by the time this podling is ready to graduate the new committers and Commons PMC will have a better knowledge of each other and there will be no issue with voting in the new committers. The use of the commons mailing lists is in the proposal and was part of the vote held on d...@commons to sponsor this incubation effort: http://markmail.org/message/mqdft736b5vasezs Niall From the first email referenced was Roman ever asked if he'd mind submitting patches for a while to earn Karma if the code did go straight to commons? Seems a bit a of a shame to need to go the whole incubation process just for one commit access. Re the the poddling use the existing commons mailing lists its may be worth pointing out this recent thread: http://apache.markmail.org/message/ifinvq7wqmeoo5ix Commons is badly busted if it can't allow a new person access to his/her own code in a fucking sandbox. Incubating this project because some weenies are uncomfortable about the nature of the meritocracy over in commons isn't the solution: have commons hold a public vote and make an actual decision. If they vote to incubate the damned thing, it's an incredibly stupid decision, but so be it. Hey Joe, the language could be toned down a bit, but I see your point. On the other hand, here is the problem as I see it. In Commons, like other non-Incubator projects, we welcome new contributors and encourage them to get involved in the community and stick around long enough to earn ASF commit. When people show up with significant patches, we ask them to file CLAs before we commit their code and if the contribution is big (not precisely defined, but we have been able to agree in all cases), we ask for a software grant and go through Incubator IP clearance. We have several examples of people showing up with large amounts of code, engaging in the community and contributing patches to their own and other code and earning commit that way. This has worked for us in the past and is consistent with how things are supposed to work - at least as I understand it - at the ASF, outside of the Incubator. If we have changed our (ASF) view on what it means to become a committer, then maybe we are behind the times in Commons. That would be somewhat ironic, since in the Jakarta days we were regularly accused of having too low a bar for commit. What we would have no problem at all with is following the process described above - just do IP clearance / code grant for the code and let the non-ASF committers earn commit. This does not take forever and is not as terrible as some seem to think it is. I can't recall a single failure (someone getting discouraged and giving up) and several successes over the past 6 years. I understand that in the Incubator people get commit immediately and that makes it easier for both them and the mentors. As I understand it, part of the reason we have the Incubator is so that people who have no experience with the ASF and have not earned merit can both gain experience and demonstrate merit in a mentored environment. The mentoring and graduation requirements ensure that when projects graduate, their committers have earned full ASF commit. It could be that I have this wrong and just arriving with a lump of code that a project wants to incorporate is enough to earn ASF commit outside the Incubator nowadays. If we collectively agreed to that and I missed the conversation, then I apologize for the late protest. I honestly can't believe that we did agree to that; however. Note that this has nothing to do with expectations
Re: [PROPOSAL] Validation incubator for JSR-303 Bean Validation
- Original Message From: Phil Steitz phil.ste...@gmail.com To: general@incubator.apache.org Sent: Wed, December 30, 2009 1:30:13 PM Subject: Re: [PROPOSAL] Validation incubator for JSR-303 Bean Validation Joe Schaefer wrote: - Original Message From: ant elder To: general@incubator.apache.org Sent: Fri, December 11, 2009 5:22:13 AM Subject: Re: [PROPOSAL] Validation incubator for JSR-303 Bean Validation On Fri, Dec 11, 2009 at 9:56 AM, Niall Pemberton wrote: On Fri, Dec 11, 2009 at 7:56 AM, ant elder wrote: A quick search so there has been some discussion on commons-dev - [1] Does this really need to be incubated - the proposal says its intended to graduate to Apache Commons and replace the existing Validator 1.x component as a new 2.0 codebase, from the discussion on commons-dev everyone seems fine with that out come, and only 2 of the 7 proposed committers are not existing Validator or ASF committers - so couldn't this just go straight to commons as a code grant and make the two new guys committers in recognition of contibuting the new code? I raised this on priv...@commons and reported back to d...@commons on that discussion here: http://markmail.org/message/lkyjl6gaxawspgdt In summary though, there was very little support to go that route and some objections. All commons components share the same set of mailing lists which makes it easier for PMC members to provide oversight for the 30+ components that live there. As part of this proposal we want to use the commons mailing lists for commits and discussion so that by the time this podling is ready to graduate the new committers and Commons PMC will have a better knowledge of each other and there will be no issue with voting in the new committers. The use of the commons mailing lists is in the proposal and was part of the vote held on d...@commons to sponsor this incubation effort: http://markmail.org/message/mqdft736b5vasezs Niall From the first email referenced was Roman ever asked if he'd mind submitting patches for a while to earn Karma if the code did go straight to commons? Seems a bit a of a shame to need to go the whole incubation process just for one commit access. Re the the poddling use the existing commons mailing lists its may be worth pointing out this recent thread: http://apache.markmail.org/message/ifinvq7wqmeoo5ix Commons is badly busted if it can't allow a new person access to his/her own code in a fucking sandbox. Incubating this project because some weenies are uncomfortable about the nature of the meritocracy over in commons isn't the solution: have commons hold a public vote and make an actual decision. If they vote to incubate the damned thing, it's an incredibly stupid decision, but so be it. Hey Joe, the language could be toned down a bit, but I see your point. On the other hand, here is the problem as I see it. In Commons, like other non-Incubator projects, we welcome new contributors and encourage them to get involved in the community and stick around long enough to earn ASF commit. When people show up with significant patches, we ask them to file CLAs before we commit their code and if the contribution is big (not precisely defined, but we have been able to agree in all cases), we ask for a software grant and go through Incubator IP clearance. We have several examples of people showing up with large amounts of code, engaging in the community and contributing patches to their own and other code and earning commit that way. This has worked for us in the past and is consistent with how things are supposed to work - at least as I understand it - at the ASF, outside of the Incubator. If we have changed our (ASF) view on what it means to become a committer, then maybe we are behind the times in Commons. That would be somewhat ironic, since in the Jakarta days we were regularly accused of having too low a bar for commit. What we would have no problem at all with is following the process described above - just do IP clearance / code grant for the code and let the non-ASF committers earn commit. This does not take forever and is not as terrible as some seem to think it is. I can't recall a single failure (someone getting discouraged and giving up) and several successes over the past 6 years. I understand that in the Incubator people get commit immediately and that makes it easier for both them and the mentors. As I understand it, part of the reason we have the Incubator is so that people who have no experience with the ASF and have not earned merit can both gain experience and demonstrate merit in a mentored environment. The mentoring and graduation requirements ensure that when projects graduate, their committers have earned full ASF commit. I seriously doubt mentors take their role that seriously, otherwise we wouldn't have so many
Re: [PROPOSAL] Validation incubator for JSR-303 Bean Validation
Joe Schaefer wrote: - Original Message From: Phil Steitz phil.ste...@gmail.com To: general@incubator.apache.org Sent: Wed, December 30, 2009 1:30:13 PM Subject: Re: [PROPOSAL] Validation incubator for JSR-303 Bean Validation Joe Schaefer wrote: - Original Message From: ant elder To: general@incubator.apache.org Sent: Fri, December 11, 2009 5:22:13 AM Subject: Re: [PROPOSAL] Validation incubator for JSR-303 Bean Validation On Fri, Dec 11, 2009 at 9:56 AM, Niall Pemberton wrote: On Fri, Dec 11, 2009 at 7:56 AM, ant elder wrote: A quick search so there has been some discussion on commons-dev - [1] Does this really need to be incubated - the proposal says its intended to graduate to Apache Commons and replace the existing Validator 1.x component as a new 2.0 codebase, from the discussion on commons-dev everyone seems fine with that out come, and only 2 of the 7 proposed committers are not existing Validator or ASF committers - so couldn't this just go straight to commons as a code grant and make the two new guys committers in recognition of contibuting the new code? I raised this on priv...@commons and reported back to d...@commons on that discussion here: http://markmail.org/message/lkyjl6gaxawspgdt In summary though, there was very little support to go that route and some objections. All commons components share the same set of mailing lists which makes it easier for PMC members to provide oversight for the 30+ components that live there. As part of this proposal we want to use the commons mailing lists for commits and discussion so that by the time this podling is ready to graduate the new committers and Commons PMC will have a better knowledge of each other and there will be no issue with voting in the new committers. The use of the commons mailing lists is in the proposal and was part of the vote held on d...@commons to sponsor this incubation effort: http://markmail.org/message/mqdft736b5vasezs Niall From the first email referenced was Roman ever asked if he'd mind submitting patches for a while to earn Karma if the code did go straight to commons? Seems a bit a of a shame to need to go the whole incubation process just for one commit access. Re the the poddling use the existing commons mailing lists its may be worth pointing out this recent thread: http://apache.markmail.org/message/ifinvq7wqmeoo5ix Commons is badly busted if it can't allow a new person access to his/her own code in a fucking sandbox. Incubating this project because some weenies are uncomfortable about the nature of the meritocracy over in commons isn't the solution: have commons hold a public vote and make an actual decision. If they vote to incubate the damned thing, it's an incredibly stupid decision, but so be it. Hey Joe, the language could be toned down a bit, but I see your point. On the other hand, here is the problem as I see it. In Commons, like other non-Incubator projects, we welcome new contributors and encourage them to get involved in the community and stick around long enough to earn ASF commit. When people show up with significant patches, we ask them to file CLAs before we commit their code and if the contribution is big (not precisely defined, but we have been able to agree in all cases), we ask for a software grant and go through Incubator IP clearance. We have several examples of people showing up with large amounts of code, engaging in the community and contributing patches to their own and other code and earning commit that way. This has worked for us in the past and is consistent with how things are supposed to work - at least as I understand it - at the ASF, outside of the Incubator. If we have changed our (ASF) view on what it means to become a committer, then maybe we are behind the times in Commons. That would be somewhat ironic, since in the Jakarta days we were regularly accused of having too low a bar for commit. What we would have no problem at all with is following the process described above - just do IP clearance / code grant for the code and let the non-ASF committers earn commit. This does not take forever and is not as terrible as some seem to think it is. I can't recall a single failure (someone getting discouraged and giving up) and several successes over the past 6 years. I understand that in the Incubator people get commit immediately and that makes it easier for both them and the mentors. As I understand it, part of the reason we have the Incubator is so that people who have no experience with the ASF and have not earned merit can both gain experience and demonstrate merit in a mentored environment. The mentoring and graduation requirements ensure that when projects graduate, their committers have earned full ASF commit. I seriously doubt mentors take their role that seriously, otherwise we wouldn't have so many long-term residents of the Incubator
Re: [PROPOSAL] Validation incubator for JSR-303 Bean Validation
On Wed, Dec 30, 2009 at 7:00 PM, Joe Schaefer joe_schae...@yahoo.com wrote: - Original Message From: Phil Steitz phil.ste...@gmail.com To: general@incubator.apache.org Sent: Wed, December 30, 2009 1:30:13 PM Subject: Re: [PROPOSAL] Validation incubator for JSR-303 Bean Validation Joe Schaefer wrote: - Original Message From: ant elder To: general@incubator.apache.org Sent: Fri, December 11, 2009 5:22:13 AM Subject: Re: [PROPOSAL] Validation incubator for JSR-303 Bean Validation On Fri, Dec 11, 2009 at 9:56 AM, Niall Pemberton wrote: On Fri, Dec 11, 2009 at 7:56 AM, ant elder wrote: A quick search so there has been some discussion on commons-dev - [1] Does this really need to be incubated - the proposal says its intended to graduate to Apache Commons and replace the existing Validator 1.x component as a new 2.0 codebase, from the discussion on commons-dev everyone seems fine with that out come, and only 2 of the 7 proposed committers are not existing Validator or ASF committers - so couldn't this just go straight to commons as a code grant and make the two new guys committers in recognition of contibuting the new code? I raised this on priv...@commons and reported back to d...@commons on that discussion here: http://markmail.org/message/lkyjl6gaxawspgdt In summary though, there was very little support to go that route and some objections. All commons components share the same set of mailing lists which makes it easier for PMC members to provide oversight for the 30+ components that live there. As part of this proposal we want to use the commons mailing lists for commits and discussion so that by the time this podling is ready to graduate the new committers and Commons PMC will have a better knowledge of each other and there will be no issue with voting in the new committers. The use of the commons mailing lists is in the proposal and was part of the vote held on d...@commons to sponsor this incubation effort: http://markmail.org/message/mqdft736b5vasezs Niall From the first email referenced was Roman ever asked if he'd mind submitting patches for a while to earn Karma if the code did go straight to commons? Seems a bit a of a shame to need to go the whole incubation process just for one commit access. Re the the poddling use the existing commons mailing lists its may be worth pointing out this recent thread: http://apache.markmail.org/message/ifinvq7wqmeoo5ix Commons is badly busted if it can't allow a new person access to his/her own code in a fucking sandbox. Incubating this project because some weenies are uncomfortable about the nature of the meritocracy over in commons isn't the solution: have commons hold a public vote and make an actual decision. If they vote to incubate the damned thing, it's an incredibly stupid decision, but so be it. Hey Joe, the language could be toned down a bit, but I see your point. On the other hand, here is the problem as I see it. In Commons, like other non-Incubator projects, we welcome new contributors and encourage them to get involved in the community and stick around long enough to earn ASF commit. When people show up with significant patches, we ask them to file CLAs before we commit their code and if the contribution is big (not precisely defined, but we have been able to agree in all cases), we ask for a software grant and go through Incubator IP clearance. We have several examples of people showing up with large amounts of code, engaging in the community and contributing patches to their own and other code and earning commit that way. This has worked for us in the past and is consistent with how things are supposed to work - at least as I understand it - at the ASF, outside of the Incubator. If we have changed our (ASF) view on what it means to become a committer, then maybe we are behind the times in Commons. That would be somewhat ironic, since in the Jakarta days we were regularly accused of having too low a bar for commit. What we would have no problem at all with is following the process described above - just do IP clearance / code grant for the code and let the non-ASF committers earn commit. This does not take forever and is not as terrible as some seem to think it is. I can't recall a single failure (someone getting discouraged and giving up) and several successes over the past 6 years. I understand that in the Incubator people get commit immediately and that makes it easier for both them and the mentors. As I understand it, part of the reason we have the Incubator is so that people who have no experience with the ASF and have not earned merit can both gain experience and demonstrate merit in a mentored environment. The mentoring and graduation requirements ensure that when projects graduate, their committers have earned full ASF commit. I seriously doubt
Re: [PROPOSAL] Validation incubator for JSR-303 Bean Validation
- Original Message From: Phil Steitz phil.ste...@gmail.com To: general@incubator.apache.org Sent: Wed, December 30, 2009 3:10:47 PM Subject: Re: [PROPOSAL] Validation incubator for JSR-303 Bean Validation Joe Schaefer wrote: - Original Message From: Phil Steitz To: general@incubator.apache.org Sent: Wed, December 30, 2009 1:30:13 PM Subject: Re: [PROPOSAL] Validation incubator for JSR-303 Bean Validation Joe Schaefer wrote: - Original Message From: ant elder To: general@incubator.apache.org Sent: Fri, December 11, 2009 5:22:13 AM Subject: Re: [PROPOSAL] Validation incubator for JSR-303 Bean Validation On Fri, Dec 11, 2009 at 9:56 AM, Niall Pemberton wrote: On Fri, Dec 11, 2009 at 7:56 AM, ant elder wrote: A quick search so there has been some discussion on commons-dev - [1] Does this really need to be incubated - the proposal says its intended to graduate to Apache Commons and replace the existing Validator 1.x component as a new 2.0 codebase, from the discussion on commons-dev everyone seems fine with that out come, and only 2 of the 7 proposed committers are not existing Validator or ASF committers - so couldn't this just go straight to commons as a code grant and make the two new guys committers in recognition of contibuting the new code? I raised this on priv...@commons and reported back to d...@commons on that discussion here: http://markmail.org/message/lkyjl6gaxawspgdt In summary though, there was very little support to go that route and some objections. All commons components share the same set of mailing lists which makes it easier for PMC members to provide oversight for the 30+ components that live there. As part of this proposal we want to use the commons mailing lists for commits and discussion so that by the time this podling is ready to graduate the new committers and Commons PMC will have a better knowledge of each other and there will be no issue with voting in the new committers. The use of the commons mailing lists is in the proposal and was part of the vote held on d...@commons to sponsor this incubation effort: http://markmail.org/message/mqdft736b5vasezs Niall From the first email referenced was Roman ever asked if he'd mind submitting patches for a while to earn Karma if the code did go straight to commons? Seems a bit a of a shame to need to go the whole incubation process just for one commit access. Re the the poddling use the existing commons mailing lists its may be worth pointing out this recent thread: http://apache.markmail.org/message/ifinvq7wqmeoo5ix Commons is badly busted if it can't allow a new person access to his/her own code in a fucking sandbox. Incubating this project because some weenies are uncomfortable about the nature of the meritocracy over in commons isn't the solution: have commons hold a public vote and make an actual decision. If they vote to incubate the damned thing, it's an incredibly stupid decision, but so be it. Hey Joe, the language could be toned down a bit, but I see your point. On the other hand, here is the problem as I see it. In Commons, like other non-Incubator projects, we welcome new contributors and encourage them to get involved in the community and stick around long enough to earn ASF commit. When people show up with significant patches, we ask them to file CLAs before we commit their code and if the contribution is big (not precisely defined, but we have been able to agree in all cases), we ask for a software grant and go through Incubator IP clearance. We have several examples of people showing up with large amounts of code, engaging in the community and contributing patches to their own and other code and earning commit that way. This has worked for us in the past and is consistent with how things are supposed to work - at least as I understand it - at the ASF, outside of the Incubator. If we have changed our (ASF) view on what it means to become a committer, then maybe we are behind the times in Commons. That would be somewhat ironic, since in the Jakarta days we were regularly accused of having too low a bar for commit. What we would have no problem at all with is following the process described above - just do IP clearance / code grant for the code and let the non-ASF committers earn commit. This does not take forever and is not as terrible as some seem to think it is. I can't recall a single failure (someone getting discouraged and giving up) and several successes over the past 6 years. I understand that in the Incubator people get commit immediately and that makes it easier for both them and the mentors. As I understand it, part of the reason we have the Incubator is so that people who have no experience with the ASF and have not earned merit can both gain experience
Re: [PROPOSAL] Validation incubator for JSR-303 Bean Validation
Joe Schaefer wrote: - Original Message From: Phil Steitz phil.ste...@gmail.com To: general@incubator.apache.org Sent: Wed, December 30, 2009 3:10:47 PM Subject: Re: [PROPOSAL] Validation incubator for JSR-303 Bean Validation Joe Schaefer wrote: - Original Message From: Phil Steitz To: general@incubator.apache.org Sent: Wed, December 30, 2009 1:30:13 PM Subject: Re: [PROPOSAL] Validation incubator for JSR-303 Bean Validation Joe Schaefer wrote: - Original Message From: ant elder To: general@incubator.apache.org Sent: Fri, December 11, 2009 5:22:13 AM Subject: Re: [PROPOSAL] Validation incubator for JSR-303 Bean Validation On Fri, Dec 11, 2009 at 9:56 AM, Niall Pemberton wrote: On Fri, Dec 11, 2009 at 7:56 AM, ant elder wrote: A quick search so there has been some discussion on commons-dev - [1] Does this really need to be incubated - the proposal says its intended to graduate to Apache Commons and replace the existing Validator 1.x component as a new 2.0 codebase, from the discussion on commons-dev everyone seems fine with that out come, and only 2 of the 7 proposed committers are not existing Validator or ASF committers - so couldn't this just go straight to commons as a code grant and make the two new guys committers in recognition of contibuting the new code? I raised this on priv...@commons and reported back to d...@commons on that discussion here: http://markmail.org/message/lkyjl6gaxawspgdt In summary though, there was very little support to go that route and some objections. All commons components share the same set of mailing lists which makes it easier for PMC members to provide oversight for the 30+ components that live there. As part of this proposal we want to use the commons mailing lists for commits and discussion so that by the time this podling is ready to graduate the new committers and Commons PMC will have a better knowledge of each other and there will be no issue with voting in the new committers. The use of the commons mailing lists is in the proposal and was part of the vote held on d...@commons to sponsor this incubation effort: http://markmail.org/message/mqdft736b5vasezs Niall From the first email referenced was Roman ever asked if he'd mind submitting patches for a while to earn Karma if the code did go straight to commons? Seems a bit a of a shame to need to go the whole incubation process just for one commit access. Re the the poddling use the existing commons mailing lists its may be worth pointing out this recent thread: http://apache.markmail.org/message/ifinvq7wqmeoo5ix Commons is badly busted if it can't allow a new person access to his/her own code in a fucking sandbox. Incubating this project because some weenies are uncomfortable about the nature of the meritocracy over in commons isn't the solution: have commons hold a public vote and make an actual decision. If they vote to incubate the damned thing, it's an incredibly stupid decision, but so be it. Hey Joe, the language could be toned down a bit, but I see your point. On the other hand, here is the problem as I see it. In Commons, like other non-Incubator projects, we welcome new contributors and encourage them to get involved in the community and stick around long enough to earn ASF commit. When people show up with significant patches, we ask them to file CLAs before we commit their code and if the contribution is big (not precisely defined, but we have been able to agree in all cases), we ask for a software grant and go through Incubator IP clearance. We have several examples of people showing up with large amounts of code, engaging in the community and contributing patches to their own and other code and earning commit that way. This has worked for us in the past and is consistent with how things are supposed to work - at least as I understand it - at the ASF, outside of the Incubator. If we have changed our (ASF) view on what it means to become a committer, then maybe we are behind the times in Commons. That would be somewhat ironic, since in the Jakarta days we were regularly accused of having too low a bar for commit. What we would have no problem at all with is following the process described above - just do IP clearance / code grant for the code and let the non-ASF committers earn commit. This does not take forever and is not as terrible as some seem to think it is. I can't recall a single failure (someone getting discouraged and giving up) and several successes over the past 6 years. I understand that in the Incubator people get commit immediately and that makes it easier for both them and the mentors. As I understand it, part of the reason we have the Incubator is so that people who have no experience with the ASF and have not earned merit can both gain experience and demonstrate merit in a mentored environment. The mentoring and graduation
Re: [PROPOSAL] Validation incubator for JSR-303 Bean Validation
+1 On Fri, Dec 11, 2009 at 3:14 AM, Donald Woods dwo...@apache.org wrote: Hello everyone, I would like to present an incubator proposal for a new Validation podling, which would be a JSR-303 Bean Validation follow-on to the existing Apache Commons Validation 1.x project, but based on a new incoming codebase with a software grant from Agimatec GmbH. The proposal is available on the wiki at: http://wiki.apache.org/incubator/ValidationProposal We're looking forward to your feedback and interest in anyone wanting to join and help out on the project. Thanks, Donald - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.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: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] Validation incubator for JSR-303 Bean Validation
It's related. Commons are sponsoring this incubation. Hen On Thu, Dec 10, 2009 at 11:06 PM, Matthias Wessendorf mat...@apache.org wrote: Hi, what about the effort from the Jakarta/Commons Validator community? Aren't they doing that as well ? (or was it only stated to do so)? -Matthias On Fri, Dec 11, 2009 at 2:14 AM, Donald Woods dwo...@apache.org wrote: Hello everyone, I would like to present an incubator proposal for a new Validation podling, which would be a JSR-303 Bean Validation follow-on to the existing Apache Commons Validation 1.x project, but based on a new incoming codebase with a software grant from Agimatec GmbH. The proposal is available on the wiki at: http://wiki.apache.org/incubator/ValidationProposal We're looking forward to your feedback and interest in anyone wanting to join and help out on the project. Thanks, Donald - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] Validation incubator for JSR-303 Bean Validation
On Fri, Dec 11, 2009 at 7:56 AM, ant elder ant.el...@gmail.com wrote: A quick search so there has been some discussion on commons-dev - [1] Does this really need to be incubated - the proposal says its intended to graduate to Apache Commons and replace the existing Validator 1.x component as a new 2.0 codebase, from the discussion on commons-dev everyone seems fine with that out come, and only 2 of the 7 proposed committers are not existing Validator or ASF committers - so couldn't this just go straight to commons as a code grant and make the two new guys committers in recognition of contibuting the new code? I raised this on priv...@commons and reported back to d...@commons on that discussion here: http://markmail.org/message/lkyjl6gaxawspgdt In summary though, there was very little support to go that route and some objections. All commons components share the same set of mailing lists which makes it easier for PMC members to provide oversight for the 30+ components that live there. As part of this proposal we want to use the commons mailing lists for commits and discussion so that by the time this podling is ready to graduate the new committers and Commons PMC will have a better knowledge of each other and there will be no issue with voting in the new committers. The use of the commons mailing lists is in the proposal and was part of the vote held on d...@commons to sponsor this incubation effort: http://markmail.org/message/mqdft736b5vasezs Niall ...ant [1] http://apache.markmail.org/search/?q=jsr+303+list%3Aorg.apache.commons.dev#query:jsr%20303%20list%3Aorg.apache.commons.dev%20order%3Adate-backward+page:1+state:facets On Fri, Dec 11, 2009 at 7:06 AM, Matthias Wessendorf mat...@apache.org wrote: Hi, what about the effort from the Jakarta/Commons Validator community? Aren't they doing that as well ? (or was it only stated to do so)? -Matthias On Fri, Dec 11, 2009 at 2:14 AM, Donald Woods dwo...@apache.org wrote: Hello everyone, I would like to present an incubator proposal for a new Validation podling, which would be a JSR-303 Bean Validation follow-on to the existing Apache Commons Validation 1.x project, but based on a new incoming codebase with a software grant from Agimatec GmbH. The proposal is available on the wiki at: http://wiki.apache.org/incubator/ValidationProposal We're looking forward to your feedback and interest in anyone wanting to join and help out on the project. Thanks, Donald - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] Validation incubator for JSR-303 Bean Validation
On Fri, Dec 11, 2009 at 9:56 AM, Niall Pemberton niall.pember...@gmail.com wrote: On Fri, Dec 11, 2009 at 7:56 AM, ant elder ant.el...@gmail.com wrote: A quick search so there has been some discussion on commons-dev - [1] Does this really need to be incubated - the proposal says its intended to graduate to Apache Commons and replace the existing Validator 1.x component as a new 2.0 codebase, from the discussion on commons-dev everyone seems fine with that out come, and only 2 of the 7 proposed committers are not existing Validator or ASF committers - so couldn't this just go straight to commons as a code grant and make the two new guys committers in recognition of contibuting the new code? I raised this on priv...@commons and reported back to d...@commons on that discussion here: http://markmail.org/message/lkyjl6gaxawspgdt In summary though, there was very little support to go that route and some objections. All commons components share the same set of mailing lists which makes it easier for PMC members to provide oversight for the 30+ components that live there. As part of this proposal we want to use the commons mailing lists for commits and discussion so that by the time this podling is ready to graduate the new committers and Commons PMC will have a better knowledge of each other and there will be no issue with voting in the new committers. The use of the commons mailing lists is in the proposal and was part of the vote held on d...@commons to sponsor this incubation effort: http://markmail.org/message/mqdft736b5vasezs Niall From the first email referenced was Roman ever asked if he'd mind submitting patches for a while to earn Karma if the code did go straight to commons? Seems a bit a of a shame to need to go the whole incubation process just for one commit access. Re the the poddling use the existing commons mailing lists its may be worth pointing out this recent thread: http://apache.markmail.org/message/ifinvq7wqmeoo5ix ...ant - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] Validation incubator for JSR-303 Bean Validation
On Fri, Dec 11, 2009 at 10:42 AM, Joe Schaefer joe_schae...@yahoo.com wrote: - Original Message From: ant elder antel...@apache.org To: general@incubator.apache.org Sent: Fri, December 11, 2009 5:22:13 AM Subject: Re: [PROPOSAL] Validation incubator for JSR-303 Bean Validation On Fri, Dec 11, 2009 at 9:56 AM, Niall Pemberton wrote: On Fri, Dec 11, 2009 at 7:56 AM, ant elder wrote: A quick search so there has been some discussion on commons-dev - [1] Does this really need to be incubated - the proposal says its intended to graduate to Apache Commons and replace the existing Validator 1.x component as a new 2.0 codebase, from the discussion on commons-dev everyone seems fine with that out come, and only 2 of the 7 proposed committers are not existing Validator or ASF committers - so couldn't this just go straight to commons as a code grant and make the two new guys committers in recognition of contibuting the new code? I raised this on priv...@commons and reported back to d...@commons on that discussion here: http://markmail.org/message/lkyjl6gaxawspgdt In summary though, there was very little support to go that route and some objections. All commons components share the same set of mailing lists which makes it easier for PMC members to provide oversight for the 30+ components that live there. As part of this proposal we want to use the commons mailing lists for commits and discussion so that by the time this podling is ready to graduate the new committers and Commons PMC will have a better knowledge of each other and there will be no issue with voting in the new committers. The use of the commons mailing lists is in the proposal and was part of the vote held on d...@commons to sponsor this incubation effort: http://markmail.org/message/mqdft736b5vasezs Niall From the first email referenced was Roman ever asked if he'd mind submitting patches for a while to earn Karma if the code did go straight to commons? Seems a bit a of a shame to need to go the whole incubation process just for one commit access. Re the the poddling use the existing commons mailing lists its may be worth pointing out this recent thread: http://apache.markmail.org/message/ifinvq7wqmeoo5ix Commons is badly busted if it can't allow a new person access to his/her own code in a fucking sandbox. Incubating this project because some weenies are uncomfortable about the nature of the meritocracy over in commons isn't the solution: Small code bases with small communities are difficult (?almost impossible?) to operate here at the ASF. Commons does OK by providing enough community and oversight to allow 30+ such small components to work here. But it relies on people taking time to keep and eye on components they have no interest in and I didn't want to jeopardize that co-operation by trying to force a decision on the sandbox. Really though, I'm not sure why you're being so abusive over this - is it really a big deal where the code sits in the subversion repository (Commons Sandbox or Incubator)? have commons hold a public vote and make an actual decision. If they vote to incubate the damned thing, it's an incredibly stupid decision, but so be it. The end result is we want this to be a proper (i.e. not Sandbox) Commons component - and that isn't going to happen with a completely unknown (to Commons) code base person. It needs an incubation period - whether thats done through the Incubator or the Sandbox - so whats the big deal? Niall - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] Validation incubator for JSR-303 Bean Validation
- Original Message From: Niall Pemberton niall.pember...@gmail.com To: general@incubator.apache.org Sent: Fri, December 11, 2009 6:29:26 AM Subject: Re: [PROPOSAL] Validation incubator for JSR-303 Bean Validation On Fri, Dec 11, 2009 at 10:42 AM, Joe Schaefer wrote: - Original Message From: ant elder To: general@incubator.apache.org Sent: Fri, December 11, 2009 5:22:13 AM Subject: Re: [PROPOSAL] Validation incubator for JSR-303 Bean Validation On Fri, Dec 11, 2009 at 9:56 AM, Niall Pemberton wrote: On Fri, Dec 11, 2009 at 7:56 AM, ant elder wrote: A quick search so there has been some discussion on commons-dev - [1] Does this really need to be incubated - the proposal says its intended to graduate to Apache Commons and replace the existing Validator 1.x component as a new 2.0 codebase, from the discussion on commons-dev everyone seems fine with that out come, and only 2 of the 7 proposed committers are not existing Validator or ASF committers - so couldn't this just go straight to commons as a code grant and make the two new guys committers in recognition of contibuting the new code? I raised this on priv...@commons and reported back to d...@commons on that discussion here: http://markmail.org/message/lkyjl6gaxawspgdt In summary though, there was very little support to go that route and some objections. All commons components share the same set of mailing lists which makes it easier for PMC members to provide oversight for the 30+ components that live there. As part of this proposal we want to use the commons mailing lists for commits and discussion so that by the time this podling is ready to graduate the new committers and Commons PMC will have a better knowledge of each other and there will be no issue with voting in the new committers. The use of the commons mailing lists is in the proposal and was part of the vote held on d...@commons to sponsor this incubation effort: http://markmail.org/message/mqdft736b5vasezs Niall From the first email referenced was Roman ever asked if he'd mind submitting patches for a while to earn Karma if the code did go straight to commons? Seems a bit a of a shame to need to go the whole incubation process just for one commit access. Re the the poddling use the existing commons mailing lists its may be worth pointing out this recent thread: http://apache.markmail.org/message/ifinvq7wqmeoo5ix Commons is badly busted if it can't allow a new person access to his/her own code in a fucking sandbox. Incubating this project because some weenies are uncomfortable about the nature of the meritocracy over in commons isn't the solution: Small code bases with small communities are difficult (?almost impossible?) to operate here at the ASF. Commons does OK by providing enough community and oversight to allow 30+ such small components to work here. But it relies on people taking time to keep and eye on components they have no interest in and I didn't want to jeopardize that co-operation by trying to force a decision on the sandbox. Really though, I'm not sure why you're being so abusive over this - is it really a big deal where the code sits in the subversion repository (Commons Sandbox or Incubator)? Sorry it's a bit early here and I haven't had my coffee, but I did not enjoy reading the discussion about this issue in the October 2009 archives of priv...@commons. The Incubator is near or at its limits in terms of what sort of oversight it can provide to its projects, and adding to that burden simply to avoid a difficult decision doesn't make much sense to me. have commons hold a public vote and make an actual decision. If they vote to incubate the damned thing, it's an incredibly stupid decision, but so be it. The end result is we want this to be a proper (i.e. not Sandbox) Commons component - and that isn't going to happen with a completely unknown (to Commons) code base person. It needs an incubation period - whether thats done through the Incubator or the Sandbox - so whats the big deal? The big deal is in how you introduce a new person into this organization. Either you're treating them as a colleague with things to learn, but with an expectation that they will succeed, or you're treating them as an outsider with something to prove, and an expectation that they will fail. That is how I view the distinction between doing the work as an IP clearance issue that is managed entirely by commons, versus punting the project into the Incubator. Niall - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr
Re: [PROPOSAL] Validation incubator for JSR-303 Bean Validation
Good points, which we discussed some on the d...@commns list before asking the Commons PMC to sponsor this as an Incubator project. My concerns, were around brining in a new codebase that previously had one maintainer, but not offering them committership from the beginning, which seemed to follow the normal meritocracy guidelines that most PMCs follow. If everyone feels that creating a podling for this effort is an overkill, then I'd be fine going the IP clearance route, as long as the existing Apache committers interested in the project are added from the start, as there doesn't seem to be a vibrant community around the existing Commons Validation project today. -Donald Joe Schaefer wrote: - Original Message From: Niall Pemberton niall.pember...@gmail.com To: general@incubator.apache.org Sent: Fri, December 11, 2009 6:29:26 AM Subject: Re: [PROPOSAL] Validation incubator for JSR-303 Bean Validation On Fri, Dec 11, 2009 at 10:42 AM, Joe Schaefer wrote: - Original Message From: ant elder To: general@incubator.apache.org Sent: Fri, December 11, 2009 5:22:13 AM Subject: Re: [PROPOSAL] Validation incubator for JSR-303 Bean Validation On Fri, Dec 11, 2009 at 9:56 AM, Niall Pemberton wrote: On Fri, Dec 11, 2009 at 7:56 AM, ant elder wrote: A quick search so there has been some discussion on commons-dev - [1] Does this really need to be incubated - the proposal says its intended to graduate to Apache Commons and replace the existing Validator 1.x component as a new 2.0 codebase, from the discussion on commons-dev everyone seems fine with that out come, and only 2 of the 7 proposed committers are not existing Validator or ASF committers - so couldn't this just go straight to commons as a code grant and make the two new guys committers in recognition of contibuting the new code? I raised this on priv...@commons and reported back to d...@commons on that discussion here: http://markmail.org/message/lkyjl6gaxawspgdt In summary though, there was very little support to go that route and some objections. All commons components share the same set of mailing lists which makes it easier for PMC members to provide oversight for the 30+ components that live there. As part of this proposal we want to use the commons mailing lists for commits and discussion so that by the time this podling is ready to graduate the new committers and Commons PMC will have a better knowledge of each other and there will be no issue with voting in the new committers. The use of the commons mailing lists is in the proposal and was part of the vote held on d...@commons to sponsor this incubation effort: http://markmail.org/message/mqdft736b5vasezs Niall From the first email referenced was Roman ever asked if he'd mind submitting patches for a while to earn Karma if the code did go straight to commons? Seems a bit a of a shame to need to go the whole incubation process just for one commit access. Re the the poddling use the existing commons mailing lists its may be worth pointing out this recent thread: http://apache.markmail.org/message/ifinvq7wqmeoo5ix Commons is badly busted if it can't allow a new person access to his/her own code in a fucking sandbox. Incubating this project because some weenies are uncomfortable about the nature of the meritocracy over in commons isn't the solution: Small code bases with small communities are difficult (?almost impossible?) to operate here at the ASF. Commons does OK by providing enough community and oversight to allow 30+ such small components to work here. But it relies on people taking time to keep and eye on components they have no interest in and I didn't want to jeopardize that co-operation by trying to force a decision on the sandbox. Really though, I'm not sure why you're being so abusive over this - is it really a big deal where the code sits in the subversion repository (Commons Sandbox or Incubator)? Sorry it's a bit early here and I haven't had my coffee, but I did not enjoy reading the discussion about this issue in the October 2009 archives of priv...@commons. The Incubator is near or at its limits in terms of what sort of oversight it can provide to its projects, and adding to that burden simply to avoid a difficult decision doesn't make much sense to me. have commons hold a public vote and make an actual decision. If they vote to incubate the damned thing, it's an incredibly stupid decision, but so be it. The end result is we want this to be a proper (i.e. not Sandbox) Commons component - and that isn't going to happen with a completely unknown (to Commons) code base person. It needs an incubation period - whether thats done through the Incubator or the Sandbox - so whats the big deal? The big deal is in how you introduce a new person into this organization. Either you're treating them as a colleague with things to learn, but with an expectation that they will succeed, or you're treating them as an outsider with something
Re: [PROPOSAL] Validation incubator for JSR-303 Bean Validation
I've said my peace on this issue. If the committer(s) need mentors to help them learn the ropes, try working with the new d...@community.apache.org list to set up a formal arrangement. OTOH I won't stand in the way if commons insists on incubating this effort. - Original Message From: Donald Woods dwo...@apache.org To: general@incubator.apache.org Sent: Fri, December 11, 2009 12:08:50 PM Subject: Re: [PROPOSAL] Validation incubator for JSR-303 Bean Validation Good points, which we discussed some on the d...@commns list before asking the Commons PMC to sponsor this as an Incubator project. My concerns, were around brining in a new codebase that previously had one maintainer, but not offering them committership from the beginning, which seemed to follow the normal meritocracy guidelines that most PMCs follow. If everyone feels that creating a podling for this effort is an overkill, then I'd be fine going the IP clearance route, as long as the existing Apache committers interested in the project are added from the start, as there doesn't seem to be a vibrant community around the existing Commons Validation project today. -Donald Joe Schaefer wrote: - Original Message From: Niall Pemberton To: general@incubator.apache.org Sent: Fri, December 11, 2009 6:29:26 AM Subject: Re: [PROPOSAL] Validation incubator for JSR-303 Bean Validation On Fri, Dec 11, 2009 at 10:42 AM, Joe Schaefer wrote: - Original Message From: ant elder To: general@incubator.apache.org Sent: Fri, December 11, 2009 5:22:13 AM Subject: Re: [PROPOSAL] Validation incubator for JSR-303 Bean Validation On Fri, Dec 11, 2009 at 9:56 AM, Niall Pemberton wrote: On Fri, Dec 11, 2009 at 7:56 AM, ant elder wrote: A quick search so there has been some discussion on commons-dev - [1] Does this really need to be incubated - the proposal says its intended to graduate to Apache Commons and replace the existing Validator 1.x component as a new 2.0 codebase, from the discussion on commons-dev everyone seems fine with that out come, and only 2 of the 7 proposed committers are not existing Validator or ASF committers - so couldn't this just go straight to commons as a code grant and make the two new guys committers in recognition of contibuting the new code? I raised this on priv...@commons and reported back to d...@commons on that discussion here: http://markmail.org/message/lkyjl6gaxawspgdt In summary though, there was very little support to go that route and some objections. All commons components share the same set of mailing lists which makes it easier for PMC members to provide oversight for the 30+ components that live there. As part of this proposal we want to use the commons mailing lists for commits and discussion so that by the time this podling is ready to graduate the new committers and Commons PMC will have a better knowledge of each other and there will be no issue with voting in the new committers. The use of the commons mailing lists is in the proposal and was part of the vote held on d...@commons to sponsor this incubation effort: http://markmail.org/message/mqdft736b5vasezs Niall From the first email referenced was Roman ever asked if he'd mind submitting patches for a while to earn Karma if the code did go straight to commons? Seems a bit a of a shame to need to go the whole incubation process just for one commit access. Re the the poddling use the existing commons mailing lists its may be worth pointing out this recent thread: http://apache.markmail.org/message/ifinvq7wqmeoo5ix Commons is badly busted if it can't allow a new person access to his/her own code in a fucking sandbox. Incubating this project because some weenies are uncomfortable about the nature of the meritocracy over in commons isn't the solution: Small code bases with small communities are difficult (?almost impossible?) to operate here at the ASF. Commons does OK by providing enough community and oversight to allow 30+ such small components to work here. But it relies on people taking time to keep and eye on components they have no interest in and I didn't want to jeopardize that co-operation by trying to force a decision on the sandbox. Really though, I'm not sure why you're being so abusive over this - is it really a big deal where the code sits in the subversion repository (Commons Sandbox or Incubator)? Sorry it's a bit early here and I haven't had my coffee, but I did not enjoy reading the discussion about this issue in the October 2009 archives of priv...@commons. The Incubator is near or at its limits in terms of what sort of oversight it can provide to its projects, and adding to that burden simply to avoid a difficult decision doesn't make much sense to me. have commons hold a public vote and make an actual
Re: [PROPOSAL] Validation incubator for JSR-303 Bean Validation
On 12/11/09 1:14 AM, Donald Woods wrote: I would like to present an incubator proposal for a new Validation podling, which would be a JSR-303 Bean Validation follow-on to the existing Apache Commons Validation 1.x project, but based on a new incoming codebase with a software grant from Agimatec GmbH. The proposal is available on the wiki at: http://wiki.apache.org/incubator/ValidationProposal The proposal looks fine on paper, but I'll agree with some of the other comments that it seems a bit silly to incubate this as a disjoint project. If you have 3 capable and able mentors *and* a whole bunch of people that are already committers, why can't they mentor your one or two new committers while those people are constrained to their specific sandbox, and avoid tons of bureaucracy and overhead? I have no real idea why anyone would think that doing incubation looks like it'll have a better chance of success in this case. Put another way - what does doing incubation buy you, and why is it seen as a better option? Can you please reconsider and see if you can do this as an ip clearance only? If it helps I can hop on a mailing list and object to some objections? :-D ciao... - Leo - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[PROPOSAL] Validation incubator for JSR-303 Bean Validation
Hello everyone, I would like to present an incubator proposal for a new Validation podling, which would be a JSR-303 Bean Validation follow-on to the existing Apache Commons Validation 1.x project, but based on a new incoming codebase with a software grant from Agimatec GmbH. The proposal is available on the wiki at: http://wiki.apache.org/incubator/ValidationProposal We're looking forward to your feedback and interest in anyone wanting to join and help out on the project. Thanks, Donald - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] Validation incubator for JSR-303 Bean Validation
Hi Donald, just to support you in the proposal and renew my interest on that project, I've already been added in the possible contributors lists - I already signed and sent the Apache ICLA. Have a nice day, best regards, Simone On Fri, Dec 11, 2009 at 2:14 AM, Donald Woods dwo...@apache.org wrote: Hello everyone, I would like to present an incubator proposal for a new Validation podling, which would be a JSR-303 Bean Validation follow-on to the existing Apache Commons Validation 1.x project, but based on a new incoming codebase with a software grant from Agimatec GmbH. The proposal is available on the wiki at: http://wiki.apache.org/incubator/ValidationProposal We're looking forward to your feedback and interest in anyone wanting to join and help out on the project. Thanks, Donald - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- --- Simone Tripodi Head of Application Development Asemantics Srl Circonvallazione Trionfale 27 00195 ROMA Italy T/F +39 0639751078 MP +39 3334513930 email: strip...@asemantics.com skype: piccolo_koenma
Re: [PROPOSAL] Validation incubator for JSR-303 Bean Validation
A quick search so there has been some discussion on commons-dev - [1] Does this really need to be incubated - the proposal says its intended to graduate to Apache Commons and replace the existing Validator 1.x component as a new 2.0 codebase, from the discussion on commons-dev everyone seems fine with that out come, and only 2 of the 7 proposed committers are not existing Validator or ASF committers - so couldn't this just go straight to commons as a code grant and make the two new guys committers in recognition of contibuting the new code? ...ant [1] http://apache.markmail.org/search/?q=jsr+303+list%3Aorg.apache.commons.dev#query:jsr%20303%20list%3Aorg.apache.commons.dev%20order%3Adate-backward+page:1+state:facets On Fri, Dec 11, 2009 at 7:06 AM, Matthias Wessendorf mat...@apache.org wrote: Hi, what about the effort from the Jakarta/Commons Validator community? Aren't they doing that as well ? (or was it only stated to do so)? -Matthias On Fri, Dec 11, 2009 at 2:14 AM, Donald Woods dwo...@apache.org wrote: Hello everyone, I would like to present an incubator proposal for a new Validation podling, which would be a JSR-303 Bean Validation follow-on to the existing Apache Commons Validation 1.x project, but based on a new incoming codebase with a software grant from Agimatec GmbH. The proposal is available on the wiki at: http://wiki.apache.org/incubator/ValidationProposal We're looking forward to your feedback and interest in anyone wanting to join and help out on the project. Thanks, Donald - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
