Hi Donald... If moving the code of Agimatic into ASF going to be problematic why not to start a clean room implementation as Niall suggested ?
On Mon, Oct 26, 2009 at 4:06 PM, Donald Woods <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. I have a completed SGA from the > company (Agimatec Gmbh) that developed the code, but was working with some > other ASF members on how we should bring the code into the ASF, so guess > it's time to start discussing that here. Currently, our thoughts were to > bring it in as a subproject to an existing TLP (like Commons, OpenJPA or > Geronimo) and not create a new Incubator Podling, since we have committers > from multiple projects interested in working on a JSR-303 implementation > (Geronimo, OpenJPA, MyFaces, OpenEJB, Commons, ...). The only complication, > is that we would need to offer committership to Roman from Agimatec as soon > as the Incubator IP clearance is finished, as he would need to be the one to > remove the existing Agimatec copyright statements. Thoughts? > > > [1] > https://svn.apache.org/repos/asf/geronimo/specs/trunk/geronimo-validation_1.0_spec > > [2] http://code.google.com/p/agimatec-validation/ > > > -Donald > > > Niall Pemberton wrote: >> >> The current trunk in the validator2 sandbox is a copy of the Validator >> 1.4 code from "commons proper" - but I think we should dump all the >> existing validator framework code and just retain the "routines" >> package. Trying to maintain any sort of compatibility with the >> existing validator framework would be alot more work and code and >> create a real mess IMO and I think it would be better to not to even >> try. The "routines" package was refactored realtively recently(!) and >> can stand on its own. >> >> So I would like to propose the following direction for a Validator2 >> based on the Bean Validation Framework(JSR 303) - a project with three >> separate modules composing of: >> >> - The Bean Validation (JSR303) API - no dependencies >> - Standalone Validation Routines (based on existing validator >> routines package) - no dependencies including Bean Validation API >> - Validation Framework - JSR303 implementation (depends on two modules >> above) >> >> I have created an alternative branch in the Validator sandbox project >> based on the above approach: >> >> >> http://svn.apache.org/viewvc/commons/sandbox/validator2/branches/alternative/ >> >> I have created a "clean room" implementation of the Bean Validation >> API[1] which (hopefully) is complete except for JavaDocs. The only >> real functionality is in javax.validation.Validation - the rest are >> annotations, interfaces and exceptions. I have also copied the >> "routines" package into a standalone module[2]. So the next thing is >> to start the actual framework implementation module. >> >> How does this sound as an approach? >> >> Niall >> >> [1] >> http://svn.apache.org/viewvc/commons/sandbox/validator2/branches/alternative/validation-api/ >> [2] >> http://svn.apache.org/viewvc/commons/sandbox/validator2/branches/alternative/validation-routines/ >> [3] >> http://svn.apache.org/viewvc/commons/sandbox/validator2/branches/alternative/validation-framework/ >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: 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
