2006/1/17, Sean Schofield <[EMAIL PROTECTED]>: > > Hmm..good point. If myfaces-commons is deployed at the container level, > > but a new version of tomahawk wants a later myfaces-commons that's a > > problem. It's very bad style to require a container's libs to be > > upgraded in order to deploy a webapp, even if the new myfaces-commons > > jarfile is supposed to be binary-compatible with the old one. > > Yes but its the best solution we've come up with so far. John had > some ideas in a thread several weeks ago. I'm going to go back an > re-read them to see if I can't understand his proposal better. > > We need to get an update release out within the next few weeks and > we're not likely to reach a better solution by then. > > My 2 cents, >
Here I agree with Sean. We should also keep in mind that the commons classes we are speaking of really (should) have "commons" nature. That means: The same problem apply as it does for EVERY commons library. Many containers already use commons libraries for their own implementation. So, as a real life example: Tomcat is shipped with a version of commons-el.jar. Now, what if MyFaces needs a newer version for some reason? Should we as well repackage commons-el classes for our MyFaces implementation to solve problems before they even arise? What about all the other commons libs: commons-collections, commons-digester, commons-fileupload, commons-logging, commons-validator, ... And in the end we repackage (i.e. refactor) every third-party lib that MyFaces Impl (or Tomahawk) is using? You might say: But all this commons stuff is stable and almost never changes! Yes, they have stable APIs, but No, they are bugfixed and enhanced all the time. This is the path that we should strike. Come to a stable commons jsf API that remains compatible over the time. And if we fix bugs or enhance this lib: What's the problem with replacing the container shipped version with a new version? No need to overreact in this issue, IMO. Manfred
