together with John I have taken a look onto the shared classes, and he thinks there might be a solution to get rid of most shared classes and repackage the remaining ones as a util jar-file.
Don't know yet if this will work out though! regards, Martin On 11/3/05, Craig McClanahan <[EMAIL PROTECTED]> wrote: > > > On 11/2/05, Sean Schofield <[EMAIL PROTECTED]> wrote: > > 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. > > The original argument went like this: anyone who creates a build script > for the RI will define two properties (one for the API classes and one for > the implementation) ... and having the MyFaces distribution organized the > same way would facilitate people trying it out. However, this was primarily > an argument to split the original all-in-one jar file into two. It has less > relevance when thinking about a myfaces-share.jar file. > > Why? Because the MyFaces implementation (as does the RI implementation) > has other external dependencies as well, so build scripts would already have > to accomodate that difference. There this argument doesn't really apply to > whether myfaces-share.jar makes sense or not. > > On that topic, I *definitely* believe that it does make sense. None of us > have enough time in the day to maintain two sets of code that does the same > thing, when its much easier to share a common set. Ironically, this would > definitely put restrictions on API evolution of the shared classes ... but > those restrictions would be no different than the restrictions you > implicitly accept on any other third party libraries that are shared between > the JSF implementation and Tomahawk. And, if *anyone* is going to be > motiviated to maintain API compatibility across different versions of the > implementation and the components, it's certainly convenient not to have to > look any further than yourselves :-). > > Craig > > > > 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 > > > > > > > -- http://www.irian.at Your JSF powerhouse - JSF Trainings in English and German
