Mailing-List: contact myfaces-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "MyFaces Development" <myfaces-dev@incubator.apache.org>
Received-SPF: pass (hermes.apache.org: domain of manfred.geiler@gmail.com
 designates 64.233.184.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:references;
        b=fon3JrUwjaUNf5VpcTPRfAZ4BFkp/Z97YYNVqMFH2Cn95megIGzGlVacePkd6RhAV1beENaYuODarNhcSVi3wBgMnBATNbze1+I26dRkkJBxXDQi1AjbmYEaE3/cwk2X7ZNbW42LLFLuSOOpixLMOkMg2WwuwmEEFVs8giS5AMI=
Message-ID: <564d4f68050412021341629a14@mail.gmail.com>
Date: Tue, 12 Apr 2005 11:13:23 +0200
From: Manfred Geiler <manfred.geiler@gmail.com>
Reply-To: Manfred Geiler <manfred.geiler@gmail.com>
To: MyFaces Development <myfaces-dev@incubator.apache.org>,
 craigmcc@apache.org
Subject: Re: Proposal: Modest Restructuring of MyFaces Project
In-Reply-To: <f8b39ace050411111378f56c23@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
References: <2387fbc50504071154673a1793@mail.gmail.com>
	 <564d4f6805041104095bda8@mail.gmail.com>
	 <2387fbc5050411092431cccd31@mail.gmail.com>
	 <564d4f6805041109482930f13d@mail.gmail.com>
	 <2387fbc5050411110026848032@mail.gmail.com>
	 <f8b39ace050411111378f56c23@mail.gmail.com>

> > My intention was to signal new users more clearly that this library is
> > independent of the myfaces implementation: myfaces-jsfcommons, a "JSF
> > Commons Library" under the "MyFaces" brand. That was the idea behind,
> > but perhaps I'm thinking too sophisticated :-)
> > I'm ok with myfaces-commons too, of course.
> >
> 
> I can see the intent, but "commons" also implies (at least from my
> Jakarta Commons biased viewpoint :-) that the stuff here is generally
> reusable, completely separate from MyFaces, and that doesn't seem
> likely for what we've been describing here.

That's exactly what is my intention: To have a place for all the stuff
that is reusable and independent from MyFaces. And that's what 99% of
the current classes in the shared src tree already are, though it
might not seem so at first glance. To give you an idea, I pick out
some classes:
- RendererUtils: a collection of convenient methods for Renderers
- MessageUtils: convenient helpers to add JSF Messages
- Html*TagBase classes: convenient base classes for writing derived Tag classes
- Html*RendererBase: convenient base classes for writing renderers
that implement or extend the functionality of standard renderers

Of course, there are small refactorings that have to be done.
And what is definitly bad now and offends the good tradition of
jakarta commons classes is the lack of documentation. To have a really
commonly usable myfaces-commons lib there is definitly some work to be
done.
So I still feel confident that myfaces-commons would be a name that
makes perfect sense even if it is an ambitious goal to aim at.

>  Consider:
> * support
> * shared
> * infrastructure

Craig, I'm not sure I understand what you mean. Are these your name
proposals or hints for issues we should consider when we speak of a
separate "commons" subproject? Sorry for being slow-witted  ;-)


> > > By the way, it sounds like you agree that the
> > > API and Impl jars should be part of a single
> > > implementation project right?
> >
> > Yes, IMHO, we are allowed to focus the user first, that needs both API
> > and Impl at runtime. If we maintain a separate API jar and document
> > it, that is enough for the user, that needs only one of the JARs for
> > any special reason.
> 
> Combining the JARs will *really* do a disservice to any potential user
> that is currently using the JSF RI (with pointers to separate
> jsf-api.jar and jsf-impl.jar properties), but wants to try MyFaces.

Sorry for misleading. There must of course exist separate jars for api
and impl. No question.

-Manfred