The amount of time to start over seems like a waste, given we have an
existing ASL 2.0 licensed codebase which is 75-80% done and wanting to
come over to the ASF....
-Donald
Mohammad Nour El-Din wrote:
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
