Hi, I wanted to point out a couple of points without delving into deep discussion on their merits ;)
Tools of the pruner type exist, as Henri mentioned. I've used GenJar (http://genjar.sourceforge.net/) in the past with some success, for example. It's a nice option to have with regards to commons, though I personally don't have a need for it because I like the current units of function. I much prefer having commons-foo-1.x.jar and commons-bar-2.x.jar in my source control repository and build files, and I wouldn't combine the two any more than I would combine Sun's rt.jar with its mail.jar for example ;) The tomcat distribution uses several commons components: daemon, launcher, logging, collections, dbcp, el, pool, beanutils, digester, fileupload, and modeler. Yet we haven't found it necessary to combine these into one jar, and a desire to do so hasn't been raised on the tomcat-dev list. It's important for us to allow users to override our libraries with later/other versions, so a mishmash jar of the above libraries probably wouldn't be used. Finally, I wanted to echo earlier sentiments that the build and release process is complicated enough as it is. We didn't make it any better with the recent common maven build stuff. Let's be careful to ensure whatever we add to handle this combo build (and like Henri, I'm -0 on doing this at all) doesn't impede individual component releases. Yoav Shapira Millennium Research Informatics >-----Original Message----- >From: Henri Yandell [mailto:[EMAIL PROTECTED] >Sent: Tuesday, May 04, 2004 7:56 AM >To: Jakarta Commons Developers List >Subject: Re: [general] library management > > >[not really a direct answer of your email as I'm -0 to Commons creating >systems to create jar slices] > >Tools to do such things to jars exist already I think from the Applet >days. I know I've written something that seemed to work for binaries but >had trouble with source [due to final variable inlining]. > >Personally I think that if project A needs Collection 2.0 and project B >needs Collection 3.0, then project A needs to get a release out. > >This would be an advantage of some larger, managed by Commons, jar. It >would lag behind the releases of the minor components, much as SuSE ES and >Red Hat AS lag behind their desktop versions. > >I'd expect: Commons-J2SE.jar and Commons-J2EE.jar, the latter of which >allows things like commons-email and commons-modeler which [assuming] have >only dependencies on Commons and J2EE. > >Hen > >On Tue, 4 May 2004, Mario Ivankovits wrote: > >> *) 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] >> > > >--------------------------------------------------------------------- >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]
