I don't think we will enjoy keeping some 100+ classes in sync across
two different packages. Nor will I think that users who try to supply
a patch who enjoy this. We couldn't use svn externals either b/c the
files need to have different package statements.
That's why this code would need to either be repackaged automatically, or eliminated from the current design altogether.
The whole point of the shared code is to cut down on this type of
headache. The RI has the luxury of just providing an implementation.
They do not provide components so they don't have to share code. As
Manfred put it, this code is shared between projects for a reason.
Agreed. However, the reason is out of date because the projects are now separated (as they should be).
I agree the current situation is not ideal and I'm open to your idea
and anyone elses but so far this solution seems even worse.
If you want to use a version of tomahawk that is incompatible with
your MyFaces implementation on the web server, just upgrade the
MyFaces version. Yes its a pain but it certainly doesn't seem to be
insurmountable.
This just proves that we depend on something other than the APIs in the specification to integrate the two projects together. That indicates that we haven't ensured proper isolation between the projects.
Am I misssing something here? Is the problem more significant then
upgrading your MyFaces implementation?
I think you might be missing the point of having a standard. :-)
The implementation of the standard runtime stands alone. The implementation of any extensions to the standard also stand alone.
The current shared code approach breaks the guarantee that any combination of standard runtime implementation and standard extension implementation can work together.
The fact that a certain combination of these implementations are provided by a common set of developers should be entirely irrelevant to the end user.
John Fallows.
On 10/24/05, John Fallows <[EMAIL PROTECTED] > wrote:
> Hey Sean,
>
> On 10/24/05, Sean Schofield <[EMAIL PROTECTED]> wrote:
> > I agree the shared classes is the most important issue to focus on. I
> > also agree -1 on repackaging them. We would live to regret that
> > decision.
>
> Your current position is clear, but not your rationale. Can you
> please elabotate so that we can better understand the perceived
> downside of using this approach?
>
> Kind Regards,
> John Fallows.
>
