hi, there is no perfect solution for it (imo). (due to the limited amount of possibilities (esp. due to the quite long name of the base package).) so i think we should keep the original/current structure.
i'm currently testing extval r3 in quite different constellations. i plan to prepare the 3rd release in about 3 weeks. so there is still some time to review it. the project grew a lot -> we should take the time to review it until the vote. there will be no new features until the release. so you can extensively test the current version available in the svn (or the latest milestone which is quite similar). regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2010/2/3 Gerhard Petracek <[email protected]> > hi rudy, > > in case of SkipValidationStrategy you are right - it has to be moved as > well. > JoinValidationStrategy will be removed after some final tests. > (it was replaced by JoinValidationMetaDataStorageFilter which is based on > the new storage concept and offers a better performance.) > > regards, > gerhard > > http://www.irian.at > > Your JSF powerhouse - > JSF Consulting, Development and > Courses in English and German > > Professional Support for Apache MyFaces > > > 2010/2/3 Rudy De Busscher <[email protected]> > > 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 >>> >> >> >
