Re: [Validator] Collections dependencies

[Stephen Colebourne <sc...@btopenworld.com>]

> > 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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Re: [Validator] Collections dependencies

[robert burrell donkin <ro...@blueyonder.co.uk>]

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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Re: [Validator] Collections dependencies

[David Graham <gr...@yahoo.com>]

--- Stephen Colebourne <sc...@btopenworld.com> 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?

We can deprecate the uses of FastHashMap in Validator for its upcoming
release and replace them with Map and HashMap references for the following
release.  I'm against copying FastHashMap into Validator because that's a
stopgap measure for BeanUtils and Digester only.

David

> 
> Stephen
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 



	
		
__________________________________
Do you Yahoo!?
Friends.  Fun.  Try the all-new Yahoo! Messenger.
http://messenger.yahoo.com/ 

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org