I'm not too wild about a new jar. Craig made some good arguments a while back about keeping myfaces just two jars (impl and api).
Perhaps he can be persuaded to share his thoughts with us again? He has some relevant experience with this in the RI and trying to use the RI and MyFaces with Shale. sean On 11/2/05, Martin Marinschek <[EMAIL PROTECTED]> wrote: > 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 >
