On Tue, 2005-12-13 at 09:19 -0600, Brian K. Wallace wrote: <snip>
> I've been watching the functor/logging threads so I believe I > understand the reasoning behind your proposal, but I do not believe I > quite agree with the implementation you suggest. > > There are two distinctly different groups that are impacted by > organization: the user, and the developer. Your proposal, on the > surface, appears to be directed toward the developer (understandable > given the issues surrounding the "complex" that is commons). Viewing the > same scenario from the user's point of view, where would someone who > "just wants to use logging" (user) go? Personal opinion - "logging". As > a "user", I wouldn't care the trouble involved in building and releasing > - - I just want to use logging. The burden is then back on the "developer" > to make "whatever structure" work such that "logging" is all I need to > look at. > > While a flatter structure may work better, the "commons" is not - > personal opinion here - where the structure root should be for something > like this. A "commons-logging" with 'core','extras', 'specification', > etc., would be much easier for a user to grok than having to navigate an > endless list of now "flattened" commons components. This in no way > alleviates any issues with building the commons site, but it would most > definitely make it easier on a user (assuming documentation was > sufficiently written) to know a) where to go for logging and b) once in > the 'logging' area, what to use and for what reasons. > > Those are my views - understanding the release process as well as the > "user" process. 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? - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
