Simon Kitching wrote: > Hi guys, > > Well, you should check out some of the email discussions held on > commons-dev about this. The general conclusion was that even commons > components should avoid dependencies on other commons components where > feasable. > Well commons are absolute base libs, but there always is a huge issue if you have too much deps, because other stuff has those deps as well and you might end up in a conflict once you try to merge myfaces into other subsystems. Even commons does not manage it to be outside of commons deps.
But as others have stated, there is no sanity in having a copy paste of commons classes into the core codebase, because you end up in a maintenment mess bigger than Mount Everest. There are two ways: a) Try to keep the number of deps as small as possible and restricted to the absolut core libs. Commons Lang is probably save, while commons-httpclient would be probably a different issue. b) Push the commons stuff into its own safe namespace so that it does not conflict with external namespaces of the same namespace. (I did that recently by pushing a httpclient and its dependency into a supportive.org.apache.xxx namespaces) This can be done relatively easy via refactoring tools but it is a huge codeupdate. Sun for instance did that as well with their own Xerces bundle which they have bundled with JDK 5.0. (They pushed it into sun.org.apache.xerces or something similar) A total independence of external libs would be good bug only b) would allow that in a sane manner and still it is sort of a maintenance nightmare, because with every release you have to do the refactoring cycle all over again.
