-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 <snip> robert burrell donkin wrote: > thanks: it's good to get different perspectives and we do appreciate > folk who take the time to join the debate. > > i think that there are two different dimensions to this discussion. the > first is flatter verses deeper. the other is the fragmentation of > components. i think that you points have most force as a argument > against over-fragmentation. > > it's common to see an army of commons jars in the lib directories of > commercial J2EE projects these days. this isn't for advertising purposes > but because we've learnt some bitter lessons over the years. however > perhaps we haven't hit upon all the right answers just yet. > > the problem with deep libraries (those who have many downstream users > who are in turn used by users) is that having any dependencies is a > burden on downstream dependent libraries as is the total size of the > jar. so, the tendency is towards smaller, more focused jars with > specific features which are not mainstream provided through auxillary > components. > > perhaps this tendency is making this more difficult for direct users. > maybe one day soon we might need to start releasing coherent groups of > related components. > > opinions?
This is where I hope I misunderstood your original proposal. The "army of commons jars" (I like that term) was never a concern so if you weren't proposing fragmentation as a means of flattening, then I wholeheartedly agree. In your original mail, however, you stated "in particular, i'm thinking about proposing commons-logging-extras and commons-logging-specification as new components." When I read "new components", I read "fragment logging". With the current flurry of "get more people involved", I view such "new components" (read: fragmentation) as harming more than helping. If they were all "under" logging, leaving logging flattened internally, it would make more sense. This would still leave users going to "commons-logging" for anything logging related - maybe version 1 is actually version 1 of the core, version 3 of the extras and version 2 of the specification. I've most definitely hit on 'jar hell' from "deep libraries", both in the application server, and application spaces (to the point of having multiple classpaths in a build to accommodate different tools used which depend on different - and incompatible - versions of commons libraries). The problem with the "commons" is that there are truly very few "small focused" components - logging being one of them. Small, focused "functional subsystems"? Yes. Looking at VFS, Net, Digester. In re-reading the commons intro page as well as the charter, it appears as though either a) the direction of commons has deviated from the charter or b) the charter hasn't had any modifications to reflect actual growth in the commons - Viewing the charter as concrete leaves (a) as the only view, however I believe both (a) and (b) have been victims of "bitter lessons". <off topic, but an interesting thought> In another time and another place, a great test of Gump would be to have commons fit the charter more narrowly - but have a level below for simple routines, classes, etc to be included at the code level by "commons" (or anywhere else, but commons primarily) [how many times has an I/O routine been recoded - or worse, add commons-io as a dependency for a single method?], then a level above what fits exactly into the narrowed charter for components like Net, VFS, and Digester (those are just 'top of my head', not meant to say "only those" or "those absolutely") that truly need full (or at least major) dependencies in order to perform a broader function. </off topic, but an interesting thought> In looking at the issues surrounding logging in all it's incantations, I can't help but see the same problem farther down the road by 'flattening by fragmentation' (new components) when you have version A of extras used with version B of logging against version C of the specification - each of the three being loaded by different classloaders. If you fix this by having concrete "use this jar only when..." and "if you have that problem, remove this jar from your classpath as it's provided for you", you're inevitably tying your three separations together at some level, and your users will definitely find that level. On the bright side, you'd be absolutely forced to adhere to #3 in the charter: "Do one thing well, and keep your contracts." (at least the keeping your contracts part ;-) ) Perhaps I'm missing your intent entirely by catching on to that phrase "new components". My ... 2? cents. Brian -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (MingW32) iD8DBQFDoLPZaCoPKRow/gARAr8bAJ422EepF+icdKIGE42lsaN2UsmcqQCg+UB1 GwB8R73VDMT8ZNED0VGYWIM= =yRfR -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
