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:[EMAIL PROTECTED]
>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: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]




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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to