Hi Gerhard,
+1 but maybe a few remarks - When the refactorings are only cosmetic (like here, there is a better grouping of functional alike classes), the user of the library hasn't much benefit from it. And thus doesn't like it very much. - By moving the annotation (JoinValidation, SkipValidation), the strategy must be moved along, no ? - JoinValidationStrategy is marked deprecated, (commit related to EXTVAL-59 and EXTVAL-60, don't see the immediate link between the deprecated and the issue, but anyway) - So skipValidation is the only x.x.2 moved file, together with the CrossValidationStorageEntry indicated on the upgrade guide. - Moving classes between packages is seen during compile time of the project. So, although not pleasant for the user, it is more visible then the functional changes of the @Length and the @Pattern. So only one 'feature' skipValidation impacted and already done other similar things, so +1 regards, Rudy On 3 February 2010 14:49, Gerhard Petracek <[email protected]>wrote: > hi @ all, > > the review phase for the next extval release (r3) has been started already. > one important topic is backward compatibility. > the 3rd release will be a major version. besides a lot of new features r3 > will be the first version which offers bean-validation integration for all > jsf versions. > > i created an upgrade guide [1] for collecting changes which aren't backward > compatible. > currently there are just very few changes in the property-validation module > which are easy to fix. > > since r3 will be a major release and i know many people who started with > the current milestone and not the previous version, i think we can take the > chance for further restructurings in the validation modules. > > what's about the following suggestion? > i would like to introduce a new package which is suggested for every > validation module for shared/common stuff. > the name is e.g. "module" and in case of the property-validation module it > would be interesting to move some classes to this package. > > property-validation module: > org.apache.myfaces.extensions.validator.module.property [new] > |_ PropertyValidationModuleKey [new] > |_ PropertyValidationSkipValidationEvaluator [new] > |_ annotation > | |_ JoinValidation [moved] > | |_ SkipValidation [moved] > | |_ SkipValidationSupport [moved] > |__ initializer.component [new] > | |_ HtmlCoreComponentsComponentInitializer [moved] > |__ interceptor [new] > | |_ PropertyValidationInterceptor [moved] > |__ startup [new] > | |_ PropertyValidationModuleStartupListener [moved] > |__ storage [new] > |__ mapper [new] > | |__ PropertyValidationGroupStorageNameMapper [new] > |__ JoinValidationMetaDataStorageFilter [new] > > most of the stuff is new or internal - so we don't really have an issue > here. > however, esp. JoinValidation, SkipValidation and SkipValidationSupport are > not new and part of the api. > if we move these annotations (because they are used in base- as well as in > cross-validation), users have to fix some import statements. since these > annotations aren't used extremely often it does >not< lead to a huge effort. > to be consistent we would have the same package concept in the > bean-validation module as well > (org.apache.myfaces.extensions.validator.module.bean). in this case we don't > have an issue because the module is completely new. > > since it is a major release (imo) the impact is minimal and should be ok. > if there is no veto, i'll do the mentioned refactoring. > (for sure - i'll also create a jira issue.) > > regards, > gerhard > > [1] > http://wiki.apache.org/myfaces/Extensions/Validator/Versions/Versions/UpgradeGuide > > http://www.irian.at > > Your JSF powerhouse - > JSF Consulting, Development and > Courses in English and German > > Professional Support for Apache MyFaces >
