struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig McClanahan <craig...@apache.org>
Subject Re: [shale] jsf-commons??
Date Fri, 09 Dec 2005 18:14:14 GMT
On 12/8/05, Martin Cooper <martinc@apache.org> wrote:
>
> On 12/8/05, Mike Kienenberger <mkienenb@gmail.com> wrote:
> >
> > I think it makes the most sense to leave it under MyFaces.
> > All of the tomahawk and sandbox components directly depend upon it, as
> > does parts of the MyFaces implementation.   Moving it into another
> > project doesn't gain anything, and would make code sychronization more
> > difficult.  As long as it's a separate jar, it doesn't make any
> > difference to end-users whether it's hosted at MyFaces or another
> > project.
>
>
> It may not make a different to MyFaces end users, but, assuming the common
> code is also used by Shale, which is what I thought we were discussing
> here,
> telling JSF RI users that they have to get a component from MyFaces to use
> Shale with the RI would be a little odd...


Well, only sort of ... the tomahawk components will certainly work very
nicely with Shale, and they are from MyFaces too.

Craig


--
> Martin Cooper
>
>
> On 12/8/05, Martin Cooper <martinc@apache.org> wrote:
> > > 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
> > > >
> > > >
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > 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