Thank you for the advice, guys! I copied the getAllInterfaces() method over to my ProxyUtils class and documented that I "borrowed" it from Jakarta Commons Lang. Then, I removed my dependency on Jakarta Commons Logging, because all I was doing was printing out informational messages for debugging purposes. The only absolute runtime dependency that commons-proxy has now is the AOP Alliance API, I believe (there are numerous optional runtime dependencies and the unit tests depend on some other stuff). That one I think I'm stuck with, though. I might try to come up with a way to provide a "bridge" or "adapter" to the AOP Alliance API and come up with my own interface for method interceptors. I don't know how necessary that is, though. The AOP Alliance API is somewhat well accepted.
-----Original Message----- From: Henning P. Schmiedehausen [mailto:[EMAIL PROTECTED] Sent: Thursday, September 08, 2005 10:52 AM To: [email protected] Subject: Re: [proxy] Commons-Lang Dependency... robert burrell donkin <[EMAIL PROTECTED]> writes: >> And, the commons-email release was shot down because of its >> dependence upon commons-lang. The dependence in email, though, was exposed >> in the public API. >i'm not sure that it was shot down (there may have been enough votes to >win the day) as much as people were persuaded that the change should be >made. stephen did the right thing in submitting a patch, No it wasn't shot down for this. We could've simply ignored Stephen, because there were enough +1 votes and releases can't be vetoed anyway. However, Stephens arguments were sensible and he was decent enough to actually do the work so that there was no real argument against it. If you want to take c-e as an example, then I'd advise to do as Stephen did: Create a package private class called YourCommonsLibUtils or something and put all code that you copy out of -lang or -collections in there and clearly label from where you took it. Put some documentation into the class which clearly states that this is a package private class, not to be used by end users. >> I do have a runtime dependency >> upon Commons Logging at this time also. What are you logging? Are you doing debugging or info log messages? Or will you log errors and failures? If you do the latter, throw exceptions and let your caller log them. If you have just a bunch of log.debug() statements, best is to keep them commented out. >it's pretty hard to win when it comes to logging. JCL was created >because (in the end) libraries need to log and a single dependency on a >small bridging API seems better than the alternatives. I agree here. If you really _have_ to do logging, then at least use c-l to allow the component users choice on which log framework they want to use in the end. Best regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED] +49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development 4 - 8 - 15 - 16 - 23 - 42 --------------------------------------------------------------------- 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]
