myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Marinschek <martin.marinsc...@gmail.com>
Subject Re: myfaces-share (was RC3...)
Date Wed, 02 Nov 2005 22:31:58 GMT
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 <john.r.fallows@gmail.com> wrote:
> On 11/2/05, Martin Marinschek <martin.marinschek@gmail.com> 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 <bdudney@mac.com > 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

Mime
View raw message