myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sean Schofield <sean.schofi...@gmail.com>
Subject Re: RC3: dependency on commons-lang
Date Mon, 24 Oct 2005 14:03:24 GMT
> 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

Mime
View raw message