Apache is built upon open collaboration within a community.
Here, we have a significant code donation being offered, which would
save us months or years in jump starting a JSR-303 implementation at
Apache. Therefore, I believe the only fair approach is one that allows
the code contributor commit karma from day one, which would be he
Podling route.
We need to build a community around any JSR-303 implementation we create
and having someone join from day one who has been working on JSR-303
since April 2008, would be a great asset to have on-board.
-Donald
Mohammad Nour El-Din wrote:
Hi...
IMO, and sorry for saying that, now we've been transformed from
thinking about the project on how to get Roman involved in code
submission. IMO if this has no solution to be taken to get things up
and running fast enough so either Ron accepts that situation, or we
start doing it the way Nial started.
On Wed, Nov 4, 2009 at 3:31 PM, Niall Pemberton
<niall.pember...@gmail.com> 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?
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
