commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mario Ivankovits <ima...@apache.org>
Subject Re: [general] library management
Date Tue, 04 May 2004 07:53:10 GMT
I would like to bring something in line about this discussion - just to 
be sure - i know what you talking about ;-)

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


Mime
View raw message