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 <[email protected]>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 > <[email protected]> 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 <[email protected]> > > > >> 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 > > >
