[vfs] new dependencies

[Mario Ivankovits <im...@apache.org>]

I would like to inform the users of vfs about the fact that vfs will 
need two new dependencies in the near future:

commons-beanutils-1.6.1.jar (filesize: 115 KB)
commons-digester-1.5.jar (filesize: 106 KB)

They will be needet if you use the StandardFileSytemManager or 
VFS.getManager() as i have replaced the "manual" parsing of the 
xml-configuration by digester.
I wanted to do this as i would like to bring in a new element <globals> 
into the configuration which is used to configure certain aspects of VFS 
and i dont wanted to reinvent the weel.

I might need two or three days until i could commit this changes, i just 
wanted to inform you early enough.

If this might make a serious problem in your environment, please let me 
know.

Cheers,
Mario


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

Re: [vfs] new dependencies

[Mario Ivankovits <im...@apache.org>]

Mario Ivankovits wrote:

> If this might make a serious problem in your environment, please let 
> me know.

Received three misgivings - how bad :-(


Tim Reilly wrote:

>My personal thought on this is that 200+K is a lot. Is something like
>osjava's gj-xml sufficient?
>
No - digester is much more than just an xml-parser. It automates the 
process of reading the xml and build the necessary java object(s). xml 
attributes/element data is set on those using reflection.
Any change to the configuration file could easily be mapped to the 
according java object.


Paul Smith wrote:

>it does seem like a large dependancy just to parse a
>single configuration file.  Is it much work to modify the current parsing
>class to include the new element support?
>
For sure it might not be much work to modify the current parsing, but 
with every new option the code gets larger and larger, and every line of 
code is simple copy&past - with some minor modification so that it cant 
be reused.
My experience is to leave such a way of how the code goes as early as 
possible, as it is much more work if this is done if it is too late.


Anthony Goubard wrote:

> Note that it would increase the size of vfs from about 200K to 400K.

Those 200K you only have if you do not use any of the ftp,http,... 
libraries.

> Is there a way to keep the old manual xml parsing even is not attached 
> to the code in case someone doesn't want ot use <globals> , he would 
> then need to change a bit of code and recompiles vfs.

Gotcha! This brings me back to the idea to how vfs works - try to see if 
a class is available and configure the system accordingly.


What do you think about making these dependencies optional.
If digester&beanutils are available, vfs will use them and you could use 
the new <globals> sections, else you are stick to the old parsing with 
their limitations (which might get more and more in the future).
In the case of "globals" it could be possible to set them from within 
the application as long as init() on the FilesystemManager wasnt called. 
If one use VFS.getInstance() then this might not be possible, but it is 
not much work to instanciate the StandardFilesystemManager directly instead.


To create really small distributions i recommend to have a look at a 
jar-builder which is able to find and jar only needet classes.

-- Mario


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