Ok, let's have a look at this. Although I doubt that we will get rid of the *Renderer*Base classes.
regards, Martin On 11/2/05, John Fallows <[EMAIL PROTECTED]> wrote: > On 11/2/05, Martin Marinschek <[EMAIL PROTECTED]> wrote: > > Yes, this is another option. > > > > make myfaces-share something like a common-jsf-utils or so. > > > > Thing is that changes should not happen very often in there, then. And > > incompatible changes never. > > Right. > > This requires that the shared code be promoted to a public API, which > reduces it's ability to change/refactor over time. That's a big decision. > In general, it is usually best to keep the public API as small as reasonably > possible, so that the least number of constraints are placed on the > implementation. > > Perhaps we can implement the common code once (to avoid maintenance > headaches), but not actually share it in the same package across project > implementations (to avoid unnecessary package overlap). It should be > possible to automate this process as part of the build. > > This would allow the trunk to have a single source of truth, while deployed > implementation versions could still vary independently as they would for any > combination of standard runtime / extension to the standard. > > I think it would also be useful to do a thorough review of the actual > integration points between the shared codebase and the two different > implementations, with a goal of reducing the amount of shared code, > especially the RendererBase classes and their supporting classes. I can > look into this and report back to the group. If anyone else wants to help, > please let me know. > > Suppose we don't solve this problem. Out of all the component libraries > available for JavaServer Faces, do we really want to have to explain to end > users why the MyFaces Tomahawk project doesn't always work so well with the > MyFaces Runtime? > > Kind Regards, > John Fallows. > > > > On 11/2/05, Bill Dudney <[EMAIL PROTECTED] > wrote: > > > Hi John, > > > > > > On Nov 1, 2005, at 10:25 PM, John Fallows wrote: > > > > > > > > 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. > > > > > > > > > > I think you might be missing something here. The standard does not > > > provide sufficient definition of how the components will be > > > implemented (and perhaps that is a good thing). There is a ton of > > > common code between all components that is not defined in the > > > standard. We can choose to re-implement that functionality in > > > tomahawk, copy and repackage or put it in a separate jar. Perhaps it > > > would be better to have more detail in the API for the component > > > classes and perhaps it would not be, either way the 1.1 and 1.2 > > > versions of the spec don't have the detail needed to reuse complex > > > code across components. With the current spec its better IMO to > > > implement everything once and share it. > > > > > > I think the bottom line is that myfaces-share.jar is something like > > > commons-logging.jar. No one decries the fact that we depend on > > > logging (well perhaps 'no one' is a strong statement :-) so why > > > should we be put out by dependence on myfaces-share.jar. It could > > > just as easily be called html-utils.jar or jsf-component-building- > > > made-easy.jar or whatever. > > > > > > As far as separation of the projects goes. myfaces-impl.jar and > > > tomahawk.jar depend on myfaces-share.jar. myfaces-share.jar should > > > not depend on myfaces-impl.jar of course but could depend on myfaces- > > > api.jar. The last time I checked the dependency tree was as described > > > here so I think we are in good shape to make things look like this. > > > > > > Anyway my $0.02 on this. > > > > > > TTFN, > > > > > > -bd- > > > > > > > > > > > > -- > > > > http://www.irian.at > > Your JSF powerhouse - > > JSF Trainings in English and German > > > > -- http://www.irian.at Your JSF powerhouse - JSF Trainings in English and German
