On Wed, Nov 4, 2009 at 3:35 PM, Niall Pemberton <niall.pember...@gmail.com> wrote: > On Wed, Nov 4, 2009 at 2:35 PM, Donald Woods <dwo...@apache.org> wrote: >> >> >> Niall Pemberton wrote: >>> >>> On Mon, Nov 2, 2009 at 10:51 PM, Donald Woods <dwo...@apache.org> wrote: >>>> >>>> Niall Pemberton wrote: >>>>> >>>>> On Tue, Oct 27, 2009 at 1:50 PM, Donald Woods <dwo...@apache.org> wrote: >>>>>> >>>>>> Niall Pemberton wrote: >>>>>>> >>>>>>> On Mon, Oct 26, 2009 at 2:06 PM, Donald Woods <dwo...@apache.org> >>>>>>> wrote: >>>>>>>> >>>>>>>> Hi Nail. I'm the one who created that copy of 1.4, so it's fine if >>>>>>>> we >>>>>>>> repurpose it, see VALIDATOR-279. >>>>>>>> >>>>>>>> As far as the API, we already have a clean room copy of the 1.0 GA >>>>>>>> API >>>>>>>> created over in the Apache Geronimo Specs subproject [1], with the >>>>>>>> other >>>>>>>> Java EE spec APIs we ship, so I'd be -1 on creating another copy, see >>>>>>>> VALIDATOR-274 for history. >>>>>>>> >>>>>>>> As far as the provider implementation, I've been working with the >>>>>>>> Agimatec-Validation project [2] currently hosted on Google Code which >>>>>>>> is >>>>>>>> ASL >>>>>>>> 2.0 licensed to bring it over to Apache. >>>>>>> >>>>>>> Cool :) >>>>>>> >>>>>>>> I have a completed SGA from the >>>>>>>> company (Agimatec Gmbh) that developed the code, but was working with >>>>>>>> some >>>>>>>> other ASF members on how we should bring the code into the ASF, so >>>>>>>> guess >>>>>>>> it's time to start discussing that here. >>>>>>> >>>>>>> Has the SGA been recorded at the ASF? >>>>>> >>>>>> No, as I was waiting to see if we were going the Podling or sub-project >>>>>> route. >>>>>> >>>>>>>> Currently, our thoughts were to >>>>>>>> bring it in as a subproject to an existing TLP (like Commons, OpenJPA >>>>>>>> or >>>>>>>> Geronimo) and not create a new Incubator Podling, since we have >>>>>>>> committers >>>>>>>> from multiple projects interested in working on a JSR-303 >>>>>>>> implementation >>>>>>>> (Geronimo, OpenJPA, MyFaces, OpenEJB, Commons, ...). The only >>>>>>>> complication, >>>>>>>> is that we would need to offer committership to Roman from Agimatec >>>>>>>> as >>>>>>>> soon >>>>>>>> as the Incubator IP clearance is finished, as he would need to be the >>>>>>>> one >>>>>>>> to >>>>>>>> remove the existing Agimatec copyright statements. Thoughts? >>>>>>> >>>>>>> If we have an SGA from the Agimatec then I think anyone can remove >>>>>>> their copyright statements from the source code. However its not nice >>>>>>> IMO to take someones code and then expect them(Roman) to start >>>>>>> submitting patches and not give them access. If we did this in the >>>>>>> Commons Sandbox, then all the existing ASF committers can have access >>>>>>> straight away - but I think its unlikely that the Commons PMC will >>>>>>> grant Roman access from day one (I can ask though). If that is the >>>>>>> case then it would be better to do it as an incubator podling. We have >>>>>>> done that recently when commons accepted Sanselan from the incubator >>>>>>> and graduating should be relatively easy since Commons's requirements >>>>>>> for a component to be part of "proper" are usually 1) is it ready to >>>>>>> release and 2) does it have 3+ committers. >>>>>> >>>>>> Either a Podling or sub-project works for me. The only complication >>>>>> with >>>>>> a >>>>>> sub-project, is I'd need a Commons PMC member to work with me to submit >>>>>> the >>>>>> initial Agimatec code snapshot, IP clearance form and SGA to the >>>>>> Incubator >>>>>> for me. >>>>> >>>>> I can do that. >>>>> >>>>>> Can you start a discussion on priv...@commons about accepting the >>>>>> codebase >>>>>> and which method the community would like to follow? >>>>> >>>>> Already done. >>>> >>>> Any updates on this? >>> >>> Apologies for the delay in responding. I asked for opinions from the >>> PMC specifically on whether we could give access to the Sandbox to >>> someone who wasn't an ASF committer and didn't have a prior history of >>> contribution. Most of the PMC has been silent on this and the response >>> I did get was mixed (i.e. both for and against) so even if it was >>> possible to get a majority vote, I am not comfortable pushing for this >>> approach since I believe it would be divisive for Commons. >>> >>> This means that if we go the Commons Sandbox route, then Roman would >>> be left needing to submit patches to his own work until he'd earn't >>> enough Karma to be voted in. Personally I don't think that would be a >>> great situation unless he is completely happy doing that. So probably >>> the best approach would be to go the Incubator podling route. >>> >>> WDYT? >> >> Yep, the Podling route seems the best solution (see my other reply to >> Mohammad for thoughts of why....) >> >> Do you want me to start putting together a Proposal? Figure we can use the >> Validator sandbox to collaborate on it till it's ready for submission. > > Lets start a proposal on the incubator wiki: > http://wiki.apache.org/incubator/
I've set up a skeleton proposal here: http://wiki.apache.org/incubator/ValidationProposal I'm going to start to flesh it out Niall > Theres a guide here: > http://incubator.apache.org/guides/proposal.html > > Also I suggest we start a vote here (d...@commons) for Commons to be > the sponsoring PMC - but it might be better if we had the draft > proposal ready before calling a vote. One thought I had was (if > Commons votes to be the sponsoring PMC) that we could perhaps use the > commons mailing lists (comm...@commons & d...@commons) and JIRA - that > way it would make it easier for the Commons community to follow > along/observe. Just because Commons sponsors though it doesn't mean > that it would automatically come here when ready to graduate (AIUI) - > which might be one reason to not use Commons resources (mailing list > and JIRA). > > Niall > > >> -Donald >> >> >>> >>> Niall >>> >>>> -Donald >>>> >>>>> Niall >>>>> >>>>>> -Donald >>>>>> >>>>>>> Niall >>>>>>> >>>>>>>> [1] >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> https://svn.apache.org/repos/asf/geronimo/specs/trunk/geronimo-validation_1.0_spec >>>>>>>> >>>>>>>> [2] http://code.google.com/p/agimatec-validation/ >>>>>>>> >>>>>>>> >>>>>>>> -Donald >>>>>>>> >>>>>>>> >>>>>>>> Niall Pemberton wrote: >>>>>>>>> >>>>>>>>> The current trunk in the validator2 sandbox is a copy of the >>>>>>>>> Validator >>>>>>>>> 1.4 code from "commons proper" - but I think we should dump all the >>>>>>>>> existing validator framework code and just retain the "routines" >>>>>>>>> package. Trying to maintain any sort of compatibility with the >>>>>>>>> existing validator framework would be alot more work and code and >>>>>>>>> create a real mess IMO and I think it would be better to not to even >>>>>>>>> try. The "routines" package was refactored realtively recently(!) >>>>>>>>> and >>>>>>>>> can stand on its own. >>>>>>>>> >>>>>>>>> So I would like to propose the following direction for a Validator2 >>>>>>>>> based on the Bean Validation Framework(JSR 303) - a project with >>>>>>>>> three >>>>>>>>> separate modules composing of: >>>>>>>>> >>>>>>>>> - The Bean Validation (JSR303) API - no dependencies >>>>>>>>> - Standalone Validation Routines (based on existing validator >>>>>>>>> routines package) - no dependencies including Bean Validation API >>>>>>>>> - Validation Framework - JSR303 implementation (depends on two >>>>>>>>> modules >>>>>>>>> above) >>>>>>>>> >>>>>>>>> I have created an alternative branch in the Validator sandbox >>>>>>>>> project >>>>>>>>> based on the above approach: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> http://svn.apache.org/viewvc/commons/sandbox/validator2/branches/alternative/ >>>>>>>>> >>>>>>>>> I have created a "clean room" implementation of the Bean Validation >>>>>>>>> API[1] which (hopefully) is complete except for JavaDocs. The only >>>>>>>>> real functionality is in javax.validation.Validation - the rest are >>>>>>>>> annotations, interfaces and exceptions. I have also copied the >>>>>>>>> "routines" package into a standalone module[2]. So the next thing is >>>>>>>>> to start the actual framework implementation module. >>>>>>>>> >>>>>>>>> How does this sound as an approach? >>>>>>>>> >>>>>>>>> Niall >>>>>>>>> >>>>>>>>> [1] >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> http://svn.apache.org/viewvc/commons/sandbox/validator2/branches/alternative/validation-api/ >>>>>>>>> [2] >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> http://svn.apache.org/viewvc/commons/sandbox/validator2/branches/alternative/validation-routines/ >>>>>>>>> [3] >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> http://svn.apache.org/viewvc/commons/sandbox/validator2/branches/alternative/validation-framework/ >>> > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
