Well, for me, if John achieves a way of doing this on a "automatically-in-deployment" base, then this is very much ok - if we have to copy classes manually whenever we deploy, this won't work.
regards, Martin On 11/3/05, Keijo Nurmes <[EMAIL PROTECTED]> wrote: > I imagine there is also loads of code to be refactored as shared. > It's most important that there is a clean spot (shared.jar common.jar > whatever.jar) > where to put all future common code. > > IMHO the trade-off between supporting freely mixing different versions of > myfaces libraries > and risking the quality of code is too high. > > regards, > > Keijo > > > Martin Marinschek wrote: > > >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 > > > > > > > > -- http://www.irian.at Your JSF powerhouse - JSF Trainings in English and German
