struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Cooper <mart...@apache.org>
Subject Re: [shale] jsf-commons??
Date Thu, 08 Dec 2005 23:16:24 GMT
On 12/8/05, Sean Schofield <sean.schofield@gmail.com> wrote:
>
> I think a jsf-commons project would be nice.  Craig's suggestions
> certainly make for good candidates.  There are a few in MyFaces that
> would definitely be appropriate as well.
>
> For MyFaces the plan is to rename the "share" subproject to "commons"
> and to start releasing it as its own jar.  In the shortrun I think we
> should stick with that stuff in MyFaces but in the long run, I don't
> see any problem with moving it to jakarta-commons.  There are a few
> issues to consider (such as committer rights and a different set of
> rules and conventions.)  Perhaps Craig could speak to that more
> specifically.  Ultimately we are all in the ASF family so maybe it
> wouldn't be too big of a change.


I don't think this would go to Jakarta Commons. It would, however, be a good
candidate for the Silk subproject, assuming that gets off the ground. (Think
of Silk as WebApp Commons.) Silk still seems to be pending name approval,
but once that gets cleared up, it would be a good place to build libraries
that could be shared by Shale, MyFaces, et al.

--
Martin Cooper


I think we'll need to do a careful analysis of the myfaces commons
> stuff before moving it into jakarta-commons.  I supposed most of it is
> useful beyond creating a JSF implementation b/c the stuff in there is
> basically stuff that is used for the MyFaces implementation as well as
> the Tomahawk components.  So certainly custom component builders might
> be interested.
>
> Something to consider but IMO there's no rush on this.  We have some
> major infrastructure changes coming up (Maven, zones) and then there's
> the 1.2 spec.  Plus on the Shale side we're trying to raise the
> profile of that project and get some releases out the door.
> Personally I'd rather see a few other things addressed like a "pet
> shop" type application that would show off MyFaces and Shale working
> together.  I think that would do a lot to help promote the two
> technologies.
>
> sean
>
>
> On 12/8/05, Craig McClanahan <craigmcc@apache.org> wrote:
> > On 12/8/05, Mike Kienenberger <mkienenb@gmail.com> wrote:
> > >
> > > This has come up recently on the Myfaces-dev mailing list.   We're
> > > probably going to be splitting off a "jsf commons" package at some
> > > point.   Myfaces/share contains what would probably end up in such a
> > > package.
> > >
> > > Do a search for thread "[proposal] myfaces-core.jar" on the
> > > myfaces-dev mailing list, Nov 29th to 30th.
> >
> >
> > For the simple kinds of utilities you're describing, hosting such a
> commons
> > at the MyFaces project would make a lot of sense -- all the developers
> there
> > would be JSF savvy and the users of the JSF implementation, and/or the
> > components, would both be interested in this kind of stuff.
> >
> > On the other hand, if the functionality you are implementing is very
> > specific to a framework, the utilities ought to stay with that
> framwork.  In
> > the current Shale code, for example, you could argue that the
> > LoadBundle.java and Messages.java utilities are sufficiently general
> purpose
> > that they might fit into a commons (and it would be fine with me if the
> > commons project wanted to copy them) -- but something like
> > AbstractViewController should stay in Shale because it's fundamental
> > functionality of the framework.
> >
> > AbstractFacesBean.java would be another commons candidate, because it is
> not
> > really framework specific.
> >
> > Craig
> >
> > On 12/8/05, Alexandre Poitras <alexandre.poitras@gmail.com> wrote:
> > > > I was wondering if it would be a good idea to start a jsf commons
> > > > project because every JSF applications seem to use a class Util with
> > > > the same methods or some variants of it (set and get some attributes
> > > > with binding expressions, passthrought some default attributes
> during
> > > > encoding). What do you think? Would the classes under the package
> util
> > > > in Shale be good candidates? I would like to contribute if it starts
> > > > but I can't write it all by myself because I am still far from being
> a
> > > > JSF expert.
> >
> >
> >
> > > --
> > > > Alexandre Poitras
> > > > Qu├ębec, Canada
> > > >
> > > >
> ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > > > For additional commands, e-mail: dev-help@struts.apache.org
> > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > > For additional commands, e-mail: dev-help@struts.apache.org
> > >
> > >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message