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? > 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. 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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
