On 11/2/05, Sean Schofield <[EMAIL PROTECTED]> wrote:
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
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
>
