commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Inger, Matthew" <In...@Synygy.com>
Subject RE: [beanutils] remove dependency on commons-logging
Date Wed, 12 May 2004 13:32:46 GMT
The only real issue i have with commons-logging is the
hardcoded list of loggers that are available, and having
to include the adapters for those loggers in our programs
no matter what.  It would be nice to have a service provider
(read discovery mechanism) to figure out what log package
adapters were available.  In that way, each adapter implementation
could be put in it's own jar, as well as having a strictly api/factory
jar.


-----Original Message-----
From: David Graham [mailto:grahamdavid1980@yahoo.com]
Sent: Tuesday, May 11, 2004 8:25 PM
To: Jakarta Commons Developers List
Subject: Re: [beanutils] remove dependency on commons-logging


I haven't heard any complaints from the community that commons components
are tied to commons-logging so I'm a bit confused about why we need to
decouple it.  We created logging to isolate us from specific logging
packages in the first place.  Now we need to decouple from our own
library?

IMO, the most compelling reasons for decoupling collections from other
commons components were:
1.  The dependency wasn't really needed
2.  So we don't trap users in dependency hell when 2 different commons
components use different versions of collections.

I don't see either of those benefits in removing a logging dependency.

David

--- Simon Kitching <simon@ecnetwork.co.nz> wrote:
> On Wed, 2004-05-12 at 00:53, David Graham wrote:
> > I was reluctantly in favor of copying certain Collections classes as a
> > temporary solution to removing that dependency but I don't see why we
> want
> > to permanently copy Logging classes to other projects.  Commons
> Logging is
> > an abstraction for Log4j and java.util.logging; now we're going to add
> yet
> > another abstraction above Commons Logging?  That doesn't make any
> sense to
> > me.  
> 
> I understand your concerns. A layer between libs and commons-logging
> does seem a little odd at first.
> 
> It would be nice if commons-logging were so small that it could be
> copied in its entirety into each project, allowing every project to
> access any logging library. However that isn't the case. Commons-logging
> is small and stable, but not small and stable enough for that.
> 
> Duplication of code *is* a reasonable solution, sometimes. If you wanted
> to sum up the values in an array of ints, would you find, download and
> use a library that had that code in it, or would you just write the
> necessary 3 lines of code? But of course anyone duplicating a complex
> piece of code like a fourier transform would deserve a good LARTing.
> It's a grey line.
> 
> I think duplicating one simple class and one interface in order to avoid
> a dependency on commons-logging is reasonable. However I'm happy to go
> with the majority opinion on that; as I said in another email, for the
> work *I* do with java, bundling commons-logging is not an issue.
> 
> Cheers,
> 
> Simon
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 



	
		
__________________________________
Do you Yahoo!?
Win a $20,000 Career Makeover at Yahoo! HotJobs  
http://hotjobs.sweepstakes.yahoo.com/careermakeover 

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message