> 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.
Agreed. This is a known problem that we have been grappling with. I believe we first started thinking about it when JBoss said they would be shipping MyFaces with their server. IMO the biggest concern is where MyFaces is bundled with an app server and you need to upgrade the MyFaces implementation in order to use the new Tomahawk. > 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. We are basically using #2 but its not well publicized. At some point this should all be spelled out in a Wiki or pehaps the official website and release notes. For this reason I don't anticipate Tomahawk being on its own release schedule separate from the implementation anytime soon. > 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. How do you propose we repackage this? Do you mean that the same classes would exist in different package locations? Are you sure that would be better then what we have now? > 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. That's not a bad idea in general. This could help solve more then MyFaces issues. > Kind Regards, > John Fallows. sean
