You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@bval.apache.org by Kevan Miller <ke...@gmail.com> on 2010/06/17 06:01:40 UTC
[DISCUSS] What next?
Congrats on the community's first release!
A good time to discuss plans for the community...
- what functionality should be targeted for the next release?
- graduation? where would the community like to graduate to? TLP? Sub project for an existing TLP (e.g. Commons?)
- anything else on your mind... ;-)
--kevan
Re: [DISCUSS] What next?
Posted by Roman Stumm <ro...@gmx.de>.
Am 17.06.10 06:01, schrieb Kevan Miller:
> where would the community like to graduate to? TLP? Sub project for an existing TLP (e.g. Commons?)
>
I think some time ago, there were plans that bval should become a
project like commons-validator or a successor for it. This is still my
opinion: bval as a commons-project or a separate TLP.
But this may take its time... There is no hurry. I am glad, that the
project has its own dynamic already.
Regards,
Roman
Re: [DISCUSS] What next?
Posted by Kevan Miller <ke...@gmail.com>.
On Jun 21, 2010, at 5:45 AM, Niall Pemberton wrote:
> On Thu, Jun 17, 2010 at 5:01 AM, Kevan Miller <ke...@gmail.com> wrote:
>> Congrats on the community's first release!
>>
>> A good time to discuss plans for the community...
>>
>> - what functionality should be targeted for the next release?
>> - graduation? where would the community like to graduate to? TLP? Sub project for an existing TLP (e.g. Commons?)
>> - anything else on your mind... ;-)
>
> Seems to me that bval has enough people to to sustain itself as a TLP
> and therefore that would be better.
I agree. Personally, I see enough diversity. The community has grown. The community has shown it can perform a release. And don't see any warning bells within the community. I think the community could start actively working towards graduation.
--kevan
Re: [DISCUSS] What next?
Posted by Niall Pemberton <ni...@gmail.com>.
On Thu, Jun 17, 2010 at 5:01 AM, Kevan Miller <ke...@gmail.com> wrote:
> Congrats on the community's first release!
>
> A good time to discuss plans for the community...
>
> - what functionality should be targeted for the next release?
> - graduation? where would the community like to graduate to? TLP? Sub project for an existing TLP (e.g. Commons?)
> - anything else on your mind... ;-)
Seems to me that bval has enough people to to sustain itself as a TLP
and therefore that would be better.
Niall
> --kevan
Re: [DISCUSS] What next?
Posted by Simone Tripodi <si...@gmail.com>.
Couldn't explain better, my big +1 on that!
Hasta pronto,
Simo
>
> PD: Don't get me wrong about the first point please, IMHO creating a jsr303
> compatibility layer over the existing core validator while achieving good
> code reuse is an incredible engineering task (and that's a big kudos to
> Roman). But, if the objective of the project is determined to be more in the
> line of being a jsr303 impl, I think we could gain code clarity and reduce
> complexity by moving the needed code from core to the jsr303 part and
> dropping the dependency. This would also probably make it easier for new
> people to contribute.
>
> Regards,
> Carlos
>
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
Re: [DISCUSS] What next?
Posted by Carlos Vara <ba...@gmail.com>.
Hi all,
about the possible evolution of the code, here are a few thoughts that I had
while patching it:
- There are several parts of the code in the jsr303 module that could be
made more concise/clean if they were separated from the core
superclasses/dependencies. This would be similar to the issue in BVAL-47.
Two other good examples that come to my mind are
GroupValidationContext/BeanValidationContext and
ConstraintValidationListener. The warning reported by findbugs in
ConstraintValidatorListener also illustrates this.
- When creating metabeans, all the class hierarchy is explored and merged in
the resulting metabean. I think that storing a different metabean for each
class/interface would avoid re-parsing common classes/interfaces that are
shared by many beans and probably make some operations more clear (implicit
groups). This is a big change in the code though.
- A bigger change in the code would be to change the metabean creation
procedure to the following:
For each class in the hierarchy -
1. Parse class/interface, but don't apply any rule (group inheritance,
etc.)
2. Merge XML metadata.
3. Post-process the meta tree to apply the needed rules.
In the current code, the application of some rules require some hard to
follow code which is scattered in the appenders / factory. The above would
probably clarify it and make the procedure more flexible, but it requires
quite an amount of changes in the code.
- As Simone mentions, during the patching some performance issues where
relegated to a later investigation. Now could be a good time to investigate
further into it.
- Code style, there are a few files with 2 space indentation, most are with
4. Sometimes * imports are used, sometimes not, etc. I think it would be
great if we defined a common style to use in the project :-)
PD: Don't get me wrong about the first point please, IMHO creating a jsr303
compatibility layer over the existing core validator while achieving good
code reuse is an incredible engineering task (and that's a big kudos to
Roman). But, if the objective of the project is determined to be more in the
line of being a jsr303 impl, I think we could gain code clarity and reduce
complexity by moving the needed code from core to the jsr303 part and
dropping the dependency. This would also probably make it easier for new
people to contribute.
Regards,
Carlos
On Thu, Jun 17, 2010 at 11:11 AM, Simone Tripodi
<si...@gmail.com>wrote:
> Hi all guys,
> and sorry for the lack of participation during this last month but I'm
> setting up Apache Amber at the same time :P
>
> I'm strongly +1 for a portable constraint module!!!
>
> I'd also suggest to:
>
> * reducing dependencies as possible, I noticed some commons-lang
> features are already included in our code and maybe commons-lang could
> be dropped, I'll do some test ASAP;
> * code optimizations: we had a discussion with Carlos time ago to
> improve the efficiency of implemented algorithms;
> * modules optimization: IMHO it could be nice if auxiliary code could
> be extracted from the core module and move to somewhere else;
> * documentation: my apologies, I still have to document the
> google-guice related part :(
>
> Have a nice day, all the best,
> Simo
>
> http://people.apache.org/~simonetripodi/
> http://www.99soft.org/
>
>
>
> On Thu, Jun 17, 2010 at 10:09 AM, Gerhard Petracek
> <ge...@gmail.com> wrote:
> > hi,
> >
> > #2:
> > +1 for tlp
> >
> > #3:
> > imo we should start to discuss mechanisms/concepts which aren't supported
> by
> > the current bv-api.
> > during or after prototyping a solution in a special branch, i'll discuss
> > such new features in the eg.
> >
> > regards,
> > gerhard
> >
> > http://www.irian.at
> >
> > Your JSF powerhouse -
> > JSF Consulting, Development and
> > Courses in English and German
> >
> > Professional Support for Apache MyFaces
> >
> >
> >
> > 2010/6/17 Kevan Miller <ke...@gmail.com>
> >
> >> Congrats on the community's first release!
> >>
> >> A good time to discuss plans for the community...
> >>
> >> - what functionality should be targeted for the next release?
> >> - graduation? where would the community like to graduate to? TLP? Sub
> >> project for an existing TLP (e.g. Commons?)
> >> - anything else on your mind... ;-)
> >>
> >> --kevan
> >
>
Re: [DISCUSS] What next?
Posted by Simone Tripodi <si...@gmail.com>.
Hi all guys,
and sorry for the lack of participation during this last month but I'm
setting up Apache Amber at the same time :P
I'm strongly +1 for a portable constraint module!!!
I'd also suggest to:
* reducing dependencies as possible, I noticed some commons-lang
features are already included in our code and maybe commons-lang could
be dropped, I'll do some test ASAP;
* code optimizations: we had a discussion with Carlos time ago to
improve the efficiency of implemented algorithms;
* modules optimization: IMHO it could be nice if auxiliary code could
be extracted from the core module and move to somewhere else;
* documentation: my apologies, I still have to document the
google-guice related part :(
Have a nice day, all the best,
Simo
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Thu, Jun 17, 2010 at 10:09 AM, Gerhard Petracek
<ge...@gmail.com> wrote:
> hi,
>
> #2:
> +1 for tlp
>
> #3:
> imo we should start to discuss mechanisms/concepts which aren't supported by
> the current bv-api.
> during or after prototyping a solution in a special branch, i'll discuss
> such new features in the eg.
>
> regards,
> gerhard
>
> http://www.irian.at
>
> Your JSF powerhouse -
> JSF Consulting, Development and
> Courses in English and German
>
> Professional Support for Apache MyFaces
>
>
>
> 2010/6/17 Kevan Miller <ke...@gmail.com>
>
>> Congrats on the community's first release!
>>
>> A good time to discuss plans for the community...
>>
>> - what functionality should be targeted for the next release?
>> - graduation? where would the community like to graduate to? TLP? Sub
>> project for an existing TLP (e.g. Commons?)
>> - anything else on your mind... ;-)
>>
>> --kevan
>
Re: [DISCUSS] What next?
Posted by Gerhard Petracek <ge...@gmail.com>.
hi,
#2:
+1 for tlp
#3:
imo we should start to discuss mechanisms/concepts which aren't supported by
the current bv-api.
during or after prototyping a solution in a special branch, i'll discuss
such new features in the eg.
regards,
gerhard
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2010/6/17 Kevan Miller <ke...@gmail.com>
> Congrats on the community's first release!
>
> A good time to discuss plans for the community...
>
> - what functionality should be targeted for the next release?
> - graduation? where would the community like to graduate to? TLP? Sub
> project for an existing TLP (e.g. Commons?)
> - anything else on your mind... ;-)
>
> --kevan
Re: [DISCUSS] What next?
Posted by Donald Woods <dw...@apache.org>.
On 6/17/10 12:01 AM, Kevan Miller wrote:
> Congrats on the community's first release!
>
> A good time to discuss plans for the community...
>
> - what functionality should be targeted for the next release?
Any type of code refactoring (like BVAL-1 or the ideas from Simone and
Carlos) would be top priority for a 0.2-incubating, as now is the time
for major refactoring before we have an official 1.0.0 release.
> - graduation? where would the community like to graduate to? TLP? Sub project for an existing TLP (e.g. Commons?)
I feel like we need to add a few more committers and have a
0.2-incubating release before we graduate. Not that we don't understand
how to operate in an Apache Way, but that I'd like to see a bigger
community around the project before we graduate (especially if going the
TLP route.)
As far as where we might graduate to, I'd be fine with either a TLP or a
sub-project, but in the subproject case I'd require that all of our PPMC
members become PMC members of the receiving project so we could still
perform our own releases without requiring a whole new set of oversight
voting.
> - anything else on your mind... ;-)
Performance, Samples, Docs, tooling, code style cleanup, ....
>
> --kevan
-Donald
Re: [DISCUSS] What next?
Posted by Gerhard Petracek <ge...@gmail.com>.
+1 for a portable constraint module.
regards,
gerhard
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2010/6/17 Mark Struberg <st...@yahoo.de>
> Hoi!
>
> I'd now like to split 'additional functionality' out of our core packages,
> e.g. all these neat validations like @Email, etc. See BVAL-1
>
> There are 2 reasons for it:
> .) they can be used with other JSR-303 implementations too
> .) we don't need to expose all our internal packages at compile time
>
>
> LieGrue,
> strub
>
> --- On Thu, 6/17/10, Kevan Miller <ke...@gmail.com> wrote:
>
> > From: Kevan Miller <ke...@gmail.com>
> > Subject: [DISCUSS] What next?
> > To: bval-dev@incubator.apache.org
> > Date: Thursday, June 17, 2010, 4:01 AM
> > Congrats on the community's first
> > release!
> >
> > A good time to discuss plans for the community...
> >
> > - what functionality should be targeted for the next
> > release?
> > - graduation? where would the community like to graduate
> > to? TLP? Sub project for an existing TLP (e.g. Commons?)
> > - anything else on your mind... ;-)
> >
> > --kevan
>
>
>
>
Re: [DISCUSS] What next?
Posted by Mark Struberg <st...@yahoo.de>.
Hoi!
I'd now like to split 'additional functionality' out of our core packages, e.g. all these neat validations like @Email, etc. See BVAL-1
There are 2 reasons for it:
.) they can be used with other JSR-303 implementations too
.) we don't need to expose all our internal packages at compile time
LieGrue,
strub
--- On Thu, 6/17/10, Kevan Miller <ke...@gmail.com> wrote:
> From: Kevan Miller <ke...@gmail.com>
> Subject: [DISCUSS] What next?
> To: bval-dev@incubator.apache.org
> Date: Thursday, June 17, 2010, 4:01 AM
> Congrats on the community's first
> release!
>
> A good time to discuss plans for the community...
>
> - what functionality should be targeted for the next
> release?
> - graduation? where would the community like to graduate
> to? TLP? Sub project for an existing TLP (e.g. Commons?)
> - anything else on your mind... ;-)
>
> --kevan