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. regards, Martin 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
