On 8 Jun 2004, at 09:06, Stephen Colebourne wrote:
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?
hmmm...
i suppose that it all depends on what is meant by dependencies. what's important to avoid dependency hell is to ensure that one consistent set of workable dependencies are chosen and applied consistently throughout the environment.
having thought about this a little longer, it should be best for validator (and struts) to be compiled against it's old dependencies (just as you said). users then need only to ensure that they have the right mix of compatible libraries throughout their classloaders.
for example, if a user wanted to use collections 3.x with new struts in a web app in tomcat (with the option to use collection 2.x in others), all that would be necessary would be to replace the collections 2.x and older beanutils jars in the tomcat server library with the upcoming beanutils release, remove the beanutils jar from the web-app library and replace collections 2.x release with a collections 3.x release.
- robert
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
