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 Thu, 03 Nov 2005 07:05:48 GMT
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 <craigmcc@apache.org> wrote:
>
>
> On 11/2/05, Sean Schofield <sean.schofield@gmail.com> 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 < martin.marinschek@gmail.com> 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 <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
> > >
> >
>
>


--

http://www.irian.at
Your JSF powerhouse -
JSF Trainings in English and German

Mime
View raw message