Seems not :(, wdyt should we go the way Niall started ?
On Tue, Nov 3, 2009 at 12:51 AM, 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? > > -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
