You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Gerhard Petracek <ge...@gmail.com> on 2010/02/03 14:49:21 UTC
[ExtVal] backward compatibility
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
Re: [ExtVal] backward compatibility
Posted by Bart Kummel <bk...@gmail.com>.
Hi Gerhard,
As a user of libraries, I generally don't like refactorings. I do like it to
upgrade to the last version by only dropping in a new Jar and not having to
change any code. However, I do understand that refactorings are needed
sometimes. And with a good IDE, changing the imports shouldn't be that hard.
Having said that, I agree that it is a good idea to align the structure of
the validation modules with the structure of the core. I also agree that now
is a good time to make this change.
Best regards,
Bart Kummel
On Wed, Feb 3, 2010 at 14:49, Gerhard Petracek
<ge...@gmail.com>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
>
Re: [ExtVal] backward compatibility
Posted by Gerhard Petracek <ge...@gmail.com>.
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 <ge...@gmail.com>
> 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 <rd...@gmail.com>
>
> 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 <ge...@gmail.com>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
>>>
>>
>>
>
Re: [ExtVal] backward compatibility
Posted by Gerhard Petracek <ge...@gmail.com>.
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 <rd...@gmail.com>
> 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 <ge...@gmail.com>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
>>
>
>
Re: [ExtVal] backward compatibility
Posted by Rudy De Busscher <rd...@gmail.com>.
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 <ge...@gmail.com>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
>