Mailing-List: contact dev-help@myfaces.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "MyFaces Development" <dev@myfaces.apache.org>
Received-SPF: pass (asf.osuosl.org: domain of martin.marinschek@gmail.com
 designates 66.249.82.202 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=oGkOy+7IUwwkevoRBo4jff569OVPxEw9PwiID/IcOe0Qdg1D1/RLh29K1yONy8RIq9/WlOQvJKeobdX5UoDEQRevsOy+aANhK2DzSbkiRJq8WLi8p5AINJ0BBDCN+PwkiOq2Hqxi7Nn2mwcHQPduyruqJ3xZHC8kss+p2ntN1B4=
Message-ID: <5a99335f0511022305u51f1ef9eu2bee9683cfe1fdc6@mail.gmail.com>
Date: Thu, 3 Nov 2005 08:05:48 +0100
From: Martin Marinschek <martin.marinschek@gmail.com>
Reply-To: mmarinschek@apache.org
To: MyFaces Development <dev@myfaces.apache.org>
Subject: Re: myfaces-share (was RC3...)
In-Reply-To: <f8b39ace0511022012s7ab5c3f4j8b2b00e19b919658@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <435597AC.4010104@obsidium.com>
	 <83caac420510242012q71aabdefnf3187b6292bc1f18@mail.gmail.com>
	 <2387fbc50510250630r7f1acc64qcbe9fed4c756a003@mail.gmail.com>
	 <83caac420511012125m4547d579h429da4ec27474d28@mail.gmail.com>
	 <9CC2E30D-CFD1-456C-90C8-E2D0A63F720C@mac.com>
	 <5a99335f0511020917u2b11cf07hb87b11095ee552ea@mail.gmail.com>
	 <83caac420511021429k553dbea8sdff526b44f51f647@mail.gmail.com>
	 <5a99335f0511021431m3b12d12v1a1bea1e329be407@mail.gmail.com>
	 <2387fbc50511022005r17731ce0t2ed2d80cd8b19c02@mail.gmail.com>
	 <f8b39ace0511022012s7ab5c3f4j8b2b00e19b919658@mail.gmail.com>

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 fo=
r
> the implementation) ... and having the MyFaces distribution organized the
> same way would facilitate people trying it out.  However, this was primar=
ily
> an argument to split the original all-in-one jar file into two.  It has l=
ess
> 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 h=
ave
> 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 sa=
me
> thing, when its much easier to share a common set.  Ironically, this woul=
d
> definitely put restrictions on API evolution of the shared classes ... bu=
t
> those restrictions would be no different than the restrictions you
> implicitly accept on any other third party libraries that are shared betw=
een
> 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, wh=
ich
> > > > 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 maintenanc=
e
> > > > 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 woul=
d
> for any
> > > > combination of standard runtime / extension to the standard.
> > > >
> > > >  I think it would also be useful to do a thorough review of the act=
ual
> > > > integration points between the shared codebase and the two differen=
t
> > > > 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 explai=
n
> 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 t=
he
> > > > > > > MyFaces version.  Yes its a pain but it certainly doesn't see=
m
> to be
> > > > > > > insurmountable.
> > > > > > >
> > > > > > > This just proves that we depend on something other than the A=
PIs
> in
> > > > > > > the specification to integrate the two projects together.  Th=
at
> > > > > > > indicates that we haven't ensured proper isolation between th=
e
> > > > > > > projects.
> > > > > > >
> > > > > > > Am I misssing something here?  Is the problem more significan=
t
> 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 an=
y
> > > > > > > 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. Perha=
ps
> it
> > > > > > would be better to have more detail in the API for the componen=
t
> > > > > > 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 comp=
lex
> > > > > > 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 cou=
ld
> > > > > > just as easily be called html-utils.jar or jsf-component-buildi=
ng-
> > > > > > 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 sho=
uld
> > > > > > 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