API Design: Avoid External Dependencies
When you are implementing an API it may sometimes be a temptation to use external libraries, for instance the Apache Commons or Log4J, in your API.
Don't do it, unless there is absolutely no way around!
External dependencies make your API code swell quickly. Just look at Spring, or Apache Axis for proof of that. This means larger code bases, for the end user of the API, and thus sometimes slower build time. Slow build time can be really annoying during development, and a real time robber and productivity killer.
Additionally, the version of the external dependency you are using may clash with the version used in other API's, or in the final application your API is being used in.
External dependencies are, in my opinion, primarily for use in the final applications, not in API's and frameworks. Not unless you know for sure that the final application will also use the same version of that dependency. Or, if that dependency can be swapped for a different version without problems.
My Java web framework Butterfly Web UI has a single external dependency: Butterfly DI Container. But, Butterfly Web UI uses very little functionality of Butterfly Container, so no matter what version of Butterfly Container you end up using in your web application, it will not cause problems. In addition, I control both of these API's, so it is much easier to steer clear of dependency problems.