Just one note: if you do plan a large refactoring I would suggest to split it into two steps. In first step remove the @deprecated flag and push changes, then we can easily release 2.5.15. And postpone the second step (the refactoring) till 2.6.
I do not expect large changes in 2.5.x codebase Regards -- Łukasz + 48 606 323 122 http://www.lenart.org.pl/ 2018-01-04 11:56 GMT+01:00 Yasser Zamani <[email protected]>: > > > On 1/4/2018 10:58 AM, Lukasz Lenart wrote: >> As far I understand these annotations are representation of the same >> properties which can be used in XXX-conversion.properties files >> https://struts.apache.org/core-developers/type-conversion.html#collection-and-map-support > > Thanks Łukasz! With further investigation following above link, I > discovered those codes are copied from `DefaultConversionFileProcessor`. > Then I saw in it ... > >> //for properties of classes >> else if >> (!(key.startsWith(DefaultObjectTypeDeterminer.ELEMENT_PREFIX) || >> >> key.startsWith(DefaultObjectTypeDeterminer.KEY_PREFIX) || >> >> key.startsWith(DefaultObjectTypeDeterminer.DEPRECATED_ELEMENT_PREFIX)) >> ) { > > i.e. all ORs are NOTed. Now I understand what's the problem with > `DefaultConversionAnnotationProcessor` :) Copier of those codes wished > to remove NOT but wrongly just applied on first condition and rewrote it > as tc.rule() != ConversionRule.ELEMENT while `NOT` should be refactored > to all inside () i.e. tc.rule() != ConversionRule.ELEMENT && tc.rule() > != ConversionRule.KEY && tc.rule() != ConversionRule.COLLECTION. > > Also I found a lot of XXX-conversion.properties inside test resources > and now, I could coveralls my PR DefaultConversionAnnotationProcessor > without knowing underlying details via copying current tests ;) > > Regards. > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
