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]
