commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shapira, Yoav" <Yoav.Shap...@mpi.com>
Subject RE: [vfs] new dependencies
Date Mon, 17 May 2004 12:46:25 GMT

Hi,
Whew, I'm glad other people already expressed their misgivings about
these new dependencies, as I agree with the concerns expressed.

Yoav Shapira
Millennium Research Informatics


>-----Original Message-----
>From: Mario Ivankovits [mailto:imario@apache.org]
>Sent: Monday, May 17, 2004 3:42 AM
>To: Jakarta Commons Developers List
>Subject: Re: [vfs] new dependencies
>
>Paul Smith wrote:
>
>>Yeah, that might work.  If the current xml parsing code can deal with
the
>>default xml file included in the dist that is accessed via the
>>VFS.getInstance() method, then if they need to load their own custom
xml
>>file they could load it them selves...  Perhaps that's the answer,
don't
>>even bother making digester/beanutils an optional dependancy, if the
>default
>>instance of FileSystemManager is not enough to meet you're needs, then
>just
>>require the config object to be loaded by the client code, and leave
it up
>>to the client code to 'digest' their own custom xml file into the
config
>>object.
>>
>>
>OK, no new dependencies, leave it to the client code to configure the
>system as needet.
>
>I we decide to go this way, this brings me to another question - why
not
>drop providers.xml at all.
>We could save 100KB if we avoid the dependency of xml-apis (which might
>in fact only be needet if one use jdk <= 1.2 ?)
>
>What if we put the providers.xml into some easily derivatable (is this
>the right word?) code?
>The con of this might be to have ONE way how to configure vfs - no need
>to confuse the user to use providers.xml to configure the possible
>filesystems and to force them to use client-code to configure other
>aspects of vfs.
>Has anyone of changed the providers.xml and - if so - dont want to do
>this in code?
>
>-- Mario
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: commons-dev-help@jakarta.apache.org




This e-mail, including any attachments, is a confidential business communication, and may
contain information that is confidential, proprietary and/or privileged.  This e-mail is intended
only for the individual(s) to whom it is addressed, and may not be saved, copied, printed,
disclosed or used by anyone else.  If you are not the(an) intended recipient, please immediately
delete this e-mail from your computer system and notify the sender.  Thank you.


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


Mime
View raw message