myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sean Schofield <sean.schofi...@gmail.com>
Subject Fwd: Proposal: Modest Restructuring of MyFaces Project
Date Mon, 11 Apr 2005 18:00:21 GMT
I'm forwarding Manfred's answer to the list (I assume he meant this
for all of us.)


---------- Forwarded message ----------
From: Manfred Geiler <manfred.geiler@gmail.com>
Date: Apr 11, 2005 12:48 PM
Subject: Re: Proposal: Modest Restructuring of MyFaces Project
To: Sean Schofield <sean.schofield@gmail.com>


On Apr 11, 2005 6:24 PM, Sean Schofield <sean.schofield@gmail.com> wrote:
> > Proposed official name: Apache MyFaces
> > Proposed short name: myfaces
>
> Is short name the name of the jar file/project name in CVS?

CVS module name, JIRA name, ...


> I favor the following names isntead:
>
> MyFaces Commons
> myfaces-commons
>
> These are a little less wordy.  I think we can drop JSF from the name
> since it should be obvious and I think we can drop Apache because its
> a subproject and I don't think we need the extra words to describe it.

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.


>
> > Components
> > =========
> > I think there are two opportunities:
> > 1. One major components and extensions subproject ("collection") under
> > the MyFaces umbrella that is itself divided into several subprojects:
> > Components and/or Extensions bundled together by look&feel or
> > functional or popularity.
> > 2. Several component/extension projects directly under the umbrealla
> > and beside the implementation and the jsf commons project.
> > For clearness I personally would prefer the former.
> > Proposed official name: Apache MyFaces JSF Collection
> > Proposed short name: myfaces-coll
>
> I agree with Craig on this one.  Too complicated to have subprojects
> of subprojects.  Lets just have one components subproject MyFaces
> Components (aka Tomohawk or a codeword of your choice.)  We should
> take his suggestion seriously as he and the Struts team have a lot of
> experience managing all of the subprojects in Struts.
>
> Different Look & Feel can basically be achieved by different
> renderkits (right?)  So we could could possible have different
> directories for diffferent render kits but I don't think we need the
> complexity of the additional subprojects.

ok, agreed.
What about the name "Collection" instead of "Components"? I think it
is more precise, since this subproject will be a conglomeration of
many different things: components, extensions, renderkits, bridges,
addons, ...


> 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.

-M

Mime
View raw message