+1 on the proposal :) On Wed, Nov 4, 2009 at 4: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. > > -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 >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
-- Thanks - Mohammad Nour - LinkedIn: http://www.linkedin.com/in/mnour ---- "Life is like riding a bicycle. To keep your balance you must keep moving" - Albert Einstein "Writing clean code is what you must do in order to call yourself a professional. There is no reasonable excuse for doing anything less than your best." - Clean Code: A Handbook of Agile Software Craftsmanship --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
