Thanks for responding, its useful to try to understand WHY there are isues with collections and other commons packages.
I'll correct one point of fact below - the commons-collections-SNAPSHOT is earlier in time than v3.0, and represents a state before the primitive collections got kicked out (precisely because I worried about size and scope at that point). The latest jar size is 548k. This affects your next comment. Also, FYI 2.1 to 3.0 represents a very large jump in time, over 18 months IIRC. I will try and get a breakdown of sizes within the jar at some point to try and understand this further. I evaluated the code today, and found that picking and choosing classes for a smaller jar would prove difficult - there is quite high reuse within the package, and lots of backwards compatability to consider. Finally, I would say that if you have such a small target size, then I suspect that you will always take the pick and choose (repackage) option with collections. So my question would go back to your as, if there was a collection/list/set/map only jar (no bag/bidimap/buffer/comparator/functor), would you use it? Bear in mind that in order to produce more jars, the overall size will actually have to go up. Stephen ----- Original Message ----- From: "Dain Sundstrom" <[EMAIL PROTECTED]> > I can say that it is not politics for the Geronimo project. Our goal > is to keep our stand alone kernel small (under 4mb) and a full Geronimo > server under 16mb (I'm shooting for under 8). Small size is important > as it directly effects the places where people will be using the > server. There is a demand for J2EE servers in small hardware. Anyway, > just taking a quick look at ibiblio this is the history of > commons-collections > > commons-collections-1.0.jar 84k > commons-collections-2.0.jar 88k > commons-collections-2.1.jar 161k > commons-collections-3.0.jar 506k > commons-collections-SNAPSHOT.jar 842k > > I find it hard to believe that there are almost 1mb of truly common > collections. Either way, the writing is on the wall, the package is > growing and growing quickly. Not only that, since this library is > widely used in commons, all of those projects are growing at a rapid > rate. > > Building small tight code is not easy, especially as Craig put it the > other day "perceptions of 'really common' versus 'rarely used' seem to > be awfully personal". The alternative is you end up with huge > highly-coupled libraries and no one wants to use them anymore. > > Instead of just bitching, I'll suggest a possible solution. Pick > someone in your project who understands the issues, has shown an > interest in these problems, and give them the authority to make > decisions. I know it is not very "Apache", but I believe it will work. > > -dain > > /************************* > * Dain Sundstrom > * Partner > * Core Developers Network > *************************/ > > On May 3, 2004, at 2:11 AM, robert burrell donkin wrote: > > > i definitely agree that one jar is the best solution for many users. > > for those users for whom jar size is a big issue, then i'd say for > > that for many use cases rolling a custom version (possibly repackaged) > > is the best approach. (i have heard that this is how BEA re-uses the > > commons logging stuff.) > > > > but we've been hearing that for some users - many of them influential > > open source developers - this approach is unsatisfactory. one of the > > main aims for jakarta commons was to facilitate re-use of library code > > between open source projects. there are a few of ASF projects who are > > refusing to use any jakarta commons components on principle now for > > this reason. (they want small, tight libraries.) i suspect that this > > is partly political but there is a kernel of truth in the criticisms. > > it's best to think about this kind of issue early before a momentum > > develops. > > > > certainly, i'm keen to see digester 2 (if and when it comes along) > > factored into a small core with minimal dependencies together with > > optional extensions. the binary distribution would contain both a > > single complete jar and a set of multiple jars. i hope that this > > should be able to satisfy most users and since this is just a build > > issue, i suspect that the maintenance would be minimal. > > > > - robert > > > > On 3 May 2004, at 00:41, Stephen Colebourne wrote: > > > >> So what problem are we solving? Adding extra jar files alongside the > >> complete built one creates classpath problems for users, an old > >> version of > >> the 'all' jar overriding a later version of the 'part' jar or vice > >> versa. > >> General chaos and confusion. > >> > >> People so have the ability to build their own jar files with just the > >> classes they need. > >> > >> Oh, and I'd also suggest that more jar files does involve more work > >> (maintaining and releasing), and there's a distinct lack of active > >> committers on collections as it is ;-) > >> > >> Stephen > >> > >>> On 24 Apr 2004, at 04:33, Craig R. McClanahan wrote: > >>>> A neat ideal, but perceptions of "really common" versus "rarely > >>>> used" > >>>> seem to be awfully personal. Kinda reminds me of earlier > >>>> commons-dev > >>>> discussions trying to create a "commons core" JAR that included all > >>>> of > >>>> the "really common" commons JARs, and none of the others. Needless > >>>> to > >>>> say, there was no consensus on what the contents should be :-). > >> > >> From: "robert burrell donkin" <[EMAIL PROTECTED]> > >>> i wonder whether it might be possible to separate out a core jar > >>> containing just the basic interfaces and then split the > >>> implementations > >>> into several themed jars. i still think that this should be in > >>> addition > >>> to releasing a single jar containing everything, though. > >> > >> > >> > >> --------------------------------------------------------------------- > >> 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] > > > > > --------------------------------------------------------------------- > 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]
