*) It should be possible to strip out only the needed classfiles out of the commons-project to create a new custom all-in-one.jar - right?
*) If not - at least it should be possible to pack all needet jar files together.
*) If a commons project has as dependency e.g. collections-2.0 in the project.xml while collections-3.0 is already out - there is (should be) no chance to bundle collections-3.0. Maybe the user could overrule this (and run into erros).
But here i see a problem - what if one project (A) states collections-2.0 and another one (B) states collections-3.0 as their dependency. The user might have no chance to use both together.
So beside something like pruner - a custom classloader might also be needet.
Based on an configuration - it should know, if a class must be loaded from e.g collections-2.0.jar or collections-3.0.jar. So if project-A requested a collection it should load it from collections-2.0.jar else for project-B it uses collections-3.0.jar.
I came to this if i think to upgrade to the new net-1.2 in vfs - what if one would like to use vfs and net-1.1 together. For sure - it might be no great action to upgrade to net-1.2 but for some reason it is not possible.
It would be nice to be able to use net-1.2 with vfs ONLY! (there are some other dependencies which could conflict on the users machine - webdav??)
For sure - this might only work as long as there is no reference about such a "sealed" class exported to the userspace. I am not sure, but this might often be the case.
So i see two problems: 1) to create the smallest possible jar 2) to use multiple versions of the same class in one project
-- Mario
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
