commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brian K. Wallace" <>
Subject Re: [all] auxillary components
Date Thu, 15 Dec 2005 00:07:53 GMT
Hash: SHA1

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

<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.

Version: GnuPG v1.2.5 (MingW32)


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message