> > Actually, the removal of collections classes from validator will take a > > bit longer. We still have protected FastHashMap variables that need > > to be > > replaced with Maps. > > the collections packaged FashHashMap and it's dependencies are binary > compatible (in 2.x and 3.x collections - actually, they are identical) > and will be included as part of the next beanutils release. > > beanutils, validator and digester are in similar positions (and i > suspect from craig's comments earlier that struts is also) they need > the FastHashMap class (at least so that it can be deprecated) but they > don't need the other classes which have changed. so, those classes they > need will be included as part of the beanutils distribution. > > therefore, it will be possible to remove the collections dependency by > upgrading to the upcoming beanutils. this will allow FastHashMap to be > repackaged or removed (as appropriate) in due course after deprecation.
I am +1 to the removal of the [collections] dependency here. However I must express caution at the implications of what seems to be described here. The idea appears to be that [validator] will obtain its copy of FastHashMap from [beanutils]. But this class will only be present in one release (1.7?) of [beanutils] and after that my understanding is that it will be removed. This would appear to be a very risky way of handling this, as you create a new dependency hell between [validator] and one specific release of [beanutils]. If I have understood correctly, I will -1 a valiator release :-( If the aim is to remove the [collections] depencency now, then FastHashMap should be copied (no package rename) to [validator] too. However, FastHashMap has not changed between [collections] 2.1 and 3.x, so perhaps removing the dependency is not urgent? Stephen --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
