Hi Everyone, On 10/19/05, Martin Marinschek <[EMAIL PROTECTED]> wrote: > Well, if we could do b) somewhat automatically, this would be great. > > John Fallows had proposed something like this for the shared classes > of Apache MyFaces - to make sure that Tomahawk and the impl always use > the correct implementation of the shared classes. > > John - I think this is the time at which you could convince us of your > suggestion ;)
Thanks for the segue, Martin. :-) The Apache MyFaces shared codebase is currently duplicated in both MyFaces runtime implementation and the MyFaces Tomahawk extensions. The major reason for duplicating is to allow the MyFaces Tomahawk extensions to have all the classes they need when executing on a non-MyFaces Runtime, such as the RI. Otherwise, MyFaces Tomahawk would only run in MyFaces Runtime, which would be a non-starter. However, since there is duplication, then upgrading either of these (Runtime / Tomahawk) in a deployed environment independently would cause the shared classes to be upgraded as well, for both of the projects. This assumes the classpath is setup to place the newest JAR last, which might not be the case. This problem leads to a "version conflict" for the duplicated shared code. It seems there are at least two possible resolutions to this problem. 1) repackage the shared code in each project to eliminate the impact of independent upgrades 2) require a specific version combination of MyFaces Runtime / MyFaces Tomahawk to ensure the same shared code is present in both projects, making classpath ordering unimportant As far as I know, we currently use #2. However, this places MyFaces Runtime at an unnecessary disadvantage compared to the RI. For example, any version of MyFaces Tomahawk can run on any version of the RI (assuming TCK passes!) However, each version of MyFaces Tomahawk is guaranteed to run on (and not adversely impact) exactly one version of the MyFaces Runtime. Therefore, I would recommend that we investigate solution #1 in the short term to eliminate these concerns. The same approach can be applied for other dependencies that we decide to duplicate in our codebase as discussed in this thread. In general, we should minimize (not eliminate) dependencies, and (automatically?) duplicate code only when we decide that a particular dependency has shown a track record of being sufficiently incompatible across releases. Once that dependency stabilizes, we can stop the duplication and establish the (now reliable) dependency. As far as reporting dependencies is concerned, it might be useful to deliver a built-in MyFaces ViewHandler that can serve an XML document describing the Classpath and other useful debugging information. Then end-users can include that information when filing issues in JIRA, or by request on the mailing list. Kind Regards, John Fallows. > On 10/19/05, Werner Punz <[EMAIL PROTECTED]> wrote: > > 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. > > > > > > > -- > > http://www.irian.at > Your JSF powerhouse - > JSF Trainings in English and German >
